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ABSTRACT 


A common problem between Military applications and operators is the 
consistent and meaningful exchange of data. Currently, several models and 
simulations exist for the purposes of training and analyzing military data. Due to 
the absence of an agreed-upon standard with which to represent unit data, much 
is lost during interchange and applications are not maximized. This thesis is a 
step towards a solution. 

Extensible Markup Language (XML) technology has been widely accepted 
as a standard for representing information in such a way that it is self- 
documenting, self-validating and platform independent. By using the Command 
and Control Information Exchange Data Model (C2IEDM), formerly known as 
Generic Hub, and XML it is possible to develop a representation of unit data that 
is extensible and broadly useable by tactical systems and human operators alike. 
This thesis approaches the problem exploring the Model Driven Architecture 
(MDA) and the Extensible Modeling Simulation Framework (XMSF) as possible 
overarching architectural concepts for a global solution. 

The C2IEDM is used as the core data interchange model for this research 
and applies XML technologies, schema and the Extensible Stylesheet Language 
for Transformations (XSLT) to derive a formatted data representation that is 
acceptable within the Flexible Asymmetric Simulation Technologies (FAST) 
Toolbox. The transformation example serves as template for other simulation 
programs to follow for interchange through the common base model. 

This thesis shows that by using a common data representation like 
C2IEDM coupled with the power of XML and XSLT, unit information can be 
transformed and interchanged between applications. In order to accomplish this, 
an extensive analysis is done on recently performed and ongoing research as 
well as the development of an exemplar to show how the proposed process is 
completed. The result of this work is a transformation of unit data extracted from 
an example C2IEDM instance file that is compliant with the schema for an actual 
unit order of battle tool used for modeling and simulation. 
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I. INTRODUCTION 


A. CRITICAL PROBLEM STATEMENT 

A recurring issue in simulation as well as command and control system 
(CCS) development and design is data interchange. Several constructive 
simulations exist which allow military commanders to train their staffs and 
subordinate commanders for war. However, there is not a fully operational 
simulation specifically designed to train commanders and staffs for stability and 
support operations (SASO). This is an important issue: as the United States 
moves forward in its global war on terror (GWOT), it finds itself ever increasingly 
in situations where forces must transition from combat to peace support 
operations (PSO). In order to adequately train for this, simulations and C2 
systems must communicate in order to support unit training. The data 
interchange methods employed must be generic yet complete enough to facilitate 
and foster their training use and transition from one system to another. 
Additionally, due to the size and complexity of currently available simulations, a 
host of contractor support is generally required for their implementation and use. 
Generally speaking, most simulations have been independently developed by 
different contractors and have very different data input, output and structure 
requirements that foster data interchange difficulties. This prevents them from 
being used in conjunction with one another without extensive time, effort and 
specialized interfaces, such as the High Level Architecture (HLA). 

B. OVERVIEW 

The Extensible Markup Language (XML) has become the standard by 
which businesses, government and military organizations structure and 
exchange data. The Department of Defense (DoD) sees the potential for XML’s 
use in both training and combat information exchange systems and is currently 
working toward converting many of its data driven applications into XML format 
so that data interchange is platform/application independent and complete. One 
initiative under development is the Flexible Asymmetric Simulation Technologies 
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(FAST) Toolbox. This project is creating a toolbox of simulations, databases, 
and computational models designed for future use at the unit level. The 
Diplomatic and Military Operations in a Non-Warfighting Domain (DIAMOND) 
model is one of the tools included in the FAST Toolbox. DIAMOND is a high- 
level modeling tool designed for use in PSO. Developers hope that once 
complete and validated, DIAMOND will fill the requirement for a SASO planning 
and training tool providing a simulation model suitable to draw on surrounding 
data, tools and techniques (DIAMOND, 2002). 

Additional simulations, models and a Unit Order of Battle (UOB) tool are 
also contained within the FAST Toolbox providing commanders the tools 
required to train for and analyze combat scenarios both before and during 
conflict. Different military contractors have developed each of the simulation, 
database and computational tools in the Toolbox. As part of the testing and 
validation of these technologies, the Defense Modeling and Simulation Office 
(DMSO) has asked one of its participating partners, the Naval Postgraduate 
School (NPS), to investigate the design of data interchange methods between 
the applications within the FAST Toolbox. A focus area of concern is the 
interchange of data between command and control systems and these tools. 

This thesis is another step in ongoing research to discover a solution to this 
problem using XML technologies. 

This thesis provides an example transformation of data from a data model 
used in command and control systems into another representation scheme that 
is used in a simulation/model suite. This exemplar shows that the semantic 
interchange of tactical data is possible without data loss or inaccuracy. 

C. MOTIVATION 

1. Messages from the Field 

Such capabilities are mission critical and widely needed. The following 
observations are excerpts from email messages dealing with the use of 
simulations for both training and wartime operations. Since the author is an 
Army Simulation Officer, these discussions are directly relevant and have 

provided a strong motivation for this thesis work. 
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Army Simulation Officers enroute to and from Iraq are speaking out about 
the need for simulation and modeling tools to assist them in becoming more 
relevant and useful to their commanders in mission analysis, wargaming and 
course of action development and analysis phases of planning during wartime. 
This topic of discussion was not considered an issue until units entered war with 
simulations officers assigned to them. Throughout the shooting war and now 
during the SASO phase of operations in Iraq the question has become: What do 
we do now that we are not training? 

I would hope the FA 57 (Simulations Officer) is always looking for a 
way to use simulations to support the commander. Could a FA 57 
incorporate some model or simulation into this process (our 
traditional combat operations information management process) to 
help speed up our decision making capability or provide better 
battle space visualization? The answer depends upon several 
variables: Are the tools available? Is the staff manned and 
equipped to handle such capabilities? Is the unit even receptive to 
such a concept? (personal correspondence from COL Wade B. 

Becnel, Chief, Strategic Experiential Education Group (SEEG), 

Center for Strategic Leadership (CSL), U.S. Army War College, 3 
OCT 2003). 

The answers to Colonel Becnel’s questions are no, no and again 
(generally speaking) no. Why this unfortunate situation? First, the Simulation 
Operations functional area (FA57) for Army officers, which is a part of the 
Information Operations career field, is very new. Second, as computer 
technology rapidly increases, the Army and other services find themselves 
playing catch up when trying to train their members how to successfully 
implement these new technologies. To be fully understood many of these 
technologies require users to attend advanced civil schooling which is not always 
possible. Third, the simulation and modeling tools that are available are 
generally only acceptable for use at the very highest levels for planning and 
analysis. They require a great deal of time and support to operate and in many 
cases are not interoperable. The lower the level of command, the less time there 
is for database and scenario initialization that might enable computers to 
significantly assist what experienced commanders and staffs do routinely. Thus 
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analog methods of course of action (COA) development, analysis and wargaming 
are executed the way they are taught in the school houses. 

The warfighter in an operation doesn't require a simulation that will 
tell him whether one COA is statistically better by .006 than another 
COA. What is needed, and where there is a capability gap, is a 
system that is fast enough to run through a COA, provide some 
dirty estimates on effects and deliver a credible outcome. The trick 
is that this outcome would be achieved through wargaming or 
rehearsals by the warfighter anyway if they do it analog. We need 
to leverage tools that speed up this process (personal 
correspondence from Major Mike Panko, Division Simulations 
Officer, 1®^ Armored Division, 26 October 2003). 

Additionally, the Armed Forces of the United States as well as Coalition 
forces are engaged in fast paced, unpredictable urban conflict unlike any seen 
since the street fighting of World War II. Then the enemy was uniformed and 
followed prescribed tactics, techniques and procedures that in some cases led to 
his defeat. This is not necessarily the case now. Current operations occur so 
fast that there is no time to fully utilize the simulation and modeling tools 
available. The FAST project is a step towards a solution, but due to the iterative 
nature of software development and the time required to test and evaluate useful 
tools (Crain, 2002), the tools are not available when and where they are needed 
most. The following quote emphasizes this point. 

As far as FA57s in the field and use of Sims during wartime goes I 
can only speak for 1®* Armored Division. I have been integrated in 
as a Future Ops guy and one of the Battle Majors that deploys with 
the Assault Command Post / Division Tactical Assault Command 
Post (DTAC). My job as the Division Simulations Officer is nominal 
only right now and there is nothing in the immediate future that 
would indicate otherwise. Given that the Operation Iraqi Freedom 
(OIF) has become a SASO environment there has been no call for 
Sims, at all, to think through courses of action or to look at 
contingencies. There is no time to pull anything together and frankly 
there is no way for the Division to run any kind of an exercise when 
the day-to-day business is all consuming. Only Corps and higher 
have the resources to put anything together, from my perspective 
(personal correspondence from Major Mike Panko, Division 
Simulations Officer, 1®'Armored Division, 20 SEP 2003). 
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Simulations Officers serve a dual purpose in their organizations. They are 
expected to be experts in simulation technologies as well as in tactical operations 
and training. 

One critical near-term 'deployed' role FA57s will also have to be 
prepared for and is only hinted upon in the thread is in-theater 
training (our typical garrison role). It's been a long time since the 
US Army has had to refit and/or reconstitute units and personnel in 
a combat zone, and our current field force mix of analog, digital, 
and hybrid analog-digital units will make this task even more 
complicated. With the units currently in place, casualties will create 
holes in organizations where people will have to be replaced. New 
arrivals must be quickly integrated into the units' ways and means 
of doing business. With the host of non-standard digital equipment 
we have in the inventory this role will become a critical function. 

When it comes to the digital equipment, no two divisions in the 
entire US Army have the same match of equipment unlike the more 
similar CL VII (major end items) (personal correspondence from 
Major Brandon Herl, Operations Officer, Warrior Training Center, 

Korea, 20 September 2003). 

Lastly message traffic from LTC Rene Burgess addressing the issue of 
tools available, elicited the following: 

The kicker is that we have to have the tools - low overhead, easy 
to integrate, easy to run tools that do a "good enough" job right 
now, not a perfect job some time in the future. There's a degree of 
risk in this...both from the agency that supports the right now 
requirement, and in the 57 in the field using a tool that is less than 
perfect (personal correspondence from LTC Rene Burgess, 24 
October 2003). 

2. DMSO FAST Project 

The Defense Modeling and Simulation Office (DMSO) is the DoDs lead 
agency that oversees the development, management and acquisition of modeling 
and simulation (M&S) tools throughout all of the services. At the present time 
DMSO is working on a project that promises to provide better simulation and 
modeling support to lower levels of command. DMSO’s Military Operations 
Other Than War (MOOTW) Flexible Asymmetric Simulation Technologies (FAST) 
Toolbox project is designed to provide ready access to several modeling and 
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simulation tools that will eventually assist commanders in decision support. An 
issue not yet resolved is the level of command this toolbox should support. 

According to (Crain and others, 2004) the user level is primarily corps and 
below or “is intended to be used by tactical military staff members at the division 
and brigade echelons of command and below.” This is a problem because of the 
different functionality requirements at these different levels of command. The 
Toolbox currently consists of the following pieces: 

• Interim Static Stability Model (ISSM) - A civil stability and durable peace 
model that is applicable at the strategic and operational levels of war. 

• Unit Order of Battle Data Access Tool (UOB DAT) - This tool allows users 
to tailor forces and equipment to specific missions across the levels of 
war. 

• Diplomatic and Military Operations in a Non-warfiqhtinq Domain 
(DIAMOND) - This high-level stochastic simulation is focused towards 
MOOTW operations and advances planning/analysis at the operational 
and tactical levels. 

• Joint Conflict and Tactical Simulation (JCATS) - An interactive simulation 
for conducting training and mission rehearsal at the tactical level. 

• Canadian Forces Landmine Database (CFLD) - A repository of landmine 
data for analyst training and reference. 


D. OBJECTIVES 

The main objective of this thesis is to provide an exemplar to show that 
unit data represented using XML, exchanged using the C2IEDM and transformed 
using the XSLT, provides a recipe for successful data transfer. A subsequent 
objective is to compare two versions of the C2IEDM model, one which uses a 
database to hold its data and another that strictly uses XML to describe the data. 
Figure 1 illustrates the research intent. Using the C2IEDM document oriented 
schema developed by Capt. James Neushul (Neushul, 2003) and a C2IEDM 
source file generated from that schema by XMLSpy, a stylesheet written using 
XSLT extracts and formats necessary unit information from the source file that is 
required by applications within the FAST Toolbox. A result document is created 
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and is validated against the UOB schema governing all data files used within the 
FAST Toolbox to ensure compliance. Future work suggests the development of 
additional transformations that can convert C2IEDM source files into and out of 
other formats to be used with other simulation and modeling packages within the 
DoD. 



E. ORGANIZATION OF THESIS 

Chapter I provides an introduction that encompasses a working problem 
statement, an overview of the problems involved with data interchange, the 
motivation for this thesis work, the objectives of the thesis and finally the 
organization of the thesis document. 

Chapter II discusses more background and related work that are 
referenced and expounded upon in other thesis chapters. Topics include a 
discussion of XML technologies including the Extensible Modeling and 
Simulation Framework (XMSF), an overview of the MOOTW FAST Toolbox, a 
discussion of data interoperability and interchange as well as scenario 
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interchange, the Command and Control Information Exchange Data Model 
(C2IEDM), the Battle Management Language (BML), Extensible Battle 
Management Language (XBML) and lastly the TOPTIVA application. 

Chapter III discusses the Model Driven Architecture (MDA) which is an 
enterprise-scale software development methodology. Produced by the Object 
Management Group (OMG), the MDA predicates itself on using models and 
modeling software to autogenerate computer code for processes that require 
complete documentation and that are easily updatable. The MDA is examined 
for its potential use in assisting to solve data interchange difficulties. 

Chapter IV reviews the Unit Order of Battle (UOB) Toolset and its 
component parts; Databases, Data Access Tool (DAT) and Data Interchange 
Format (DIF). UOB is an authoritative source of unit order of battle information 
due to its completeness and relative ease of use. 

Chapter V discusses the development of an exemplar transformation from 
a C2IEDM source document showing how data extracted from the C2IEDM 
model can be transformed using XSLT into a format used within the FAST 
technologies arena. This chapter introduces development of XML documents 
and schema and touches on the mental processes involved in the design and the 
development of the XSLT used for the exemplar transformation. 

Chapter VI contains conclusions based on the work accomplished, 
successes achieved and short falls experienced. Recommendations for future 
extensions of this work are discussed. 
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II. BACKGROUND AND RELATED WORK 


A. INTRODUCTION 

This chapter provides needed background by synopsizing related work 
that is referenced and utilized in this thesis. Topics include a discussion of XML 
technologies including the Extensible Modeling and Simulation Framework 
(XMSF), an overview of the Flexible Asymmetric Simulation Technologies 
(FAST) Toolbox, a discussion of data interoperability and interchange as well as 
scenario interchange, a discussion of the Army Tactical Command and Control 
Information System (ATCCIS), an introduction to the Multilateral Interoperability 
Programme (MIP) and its relationship to the Command and Control Information 
Exchange Data Model (C2IEDM). The C2IEDM is introduced and both strengths 
and weaknesses are briefly discussed. The Battle Management Language 
(BML) and Extensible Battle Management Language (XBML) are reviewed and 
the TOPTIVA application is introduced. 

B. EXTENSIBLE MODELING AND SIMULATION FRAMEWORK (XMSF) 

The Extensible Modeling and Simulation Framework (XMSF), is defined 
as a composable set of standards, profiles and recommended practices for web- 
based modeling & simulation (M&S). Its basic precept is that XML-based markup 
languages, Internet technologies and Web Services will enable a new generation 
of distributed M&S applications to emerge, develop and interoperate. XMSF 
integrates several high-level requirements derived from years of experience with 
M&S frameworks and the challenges of their effective deployment across diverse 
networks and systems (Brutzman and others, 2002). XMSF is not an application 
or architecture, but a set of standards for technical solutions as well as processes 
for building distributed solutions establishing a technical framework and an 
engineering process for M&S applications utilizing web services and technologies 
(Tolk and Pullen, 2003). 

The XMSF working group consists of several partners working on three 
action areas. Those areas are Web/XML, Internet/Networking, and Modeling and 
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Simulation (M&S). The motivation behind the XMSF project is the application of 
open standards and open source solutions to increase the efficiency and 
applicability of distributed simulation systems. 

XMSF is a work in progress and as such several key factors have been 
identified. Foremost is that XMSF must not be constrained by proprietary 
technology that would stifle the open development of new technologies. It must 
be human and agent friendly and must support composable, reusable model 
components. It must be scalable enabling simulations to interact directly over 
distributed networks. In the context of the Model Driven Architecture, XMSF can 
be viewed as a web-based, “platform specific” solution, with the objective to 
identify the necessary base functionality for distributed M&S applications (Tolk 
and Pullen, 2003). 

XMSF uses an extensible framework of XML-based languages that 
provide a bridge for legacy and future M&S requirements and systems. Three 
goals or challenges for XMSF which are of key importance to military simulation 
professionals are; 

1. To provide open, affordable, extensible modeling and simulation 
capabilities for tactical scenarios of direct use to participants 
engaged in conflict and peace operations. 

2. To improve the ease of use for developers and users, fueling rapid 
growth of interoperable simulations. 

3. To provide support for all types and domains of M&S: constructive, 
analytical, live, virtual, playback-driven, agent-based, human-in-the- 
loop, heterogeneously distributed, logistical, and others (Brutzman 
and others, 2002). 

An issue of interest when discussing XMSF is the topic of ontologies. An 
ontology is an “explicit formal specification of how to represent the objects, 
concepts and other entities that are assumed to exist in some area of interest 
and the relationships that hold among them” (Dictionary, 2004). Webster defines 
ontology as a basis of meaning of something. Ontologies require precise 
vocabularies that are acceptable to all parties. XML Schema and Namespaces 
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are two methods used within XML to establish vocabularies which then can be 
used as the basis for ontologies. Much of the work done on the XMSF project 
has yielded the fact that the capabilities for such a framework exist and are 
robust enough for web-based simulation. The main issues now revolve around 
how to integrate the many technologies into the one coherent framework. 
Ontology research leading toward creation of a Semantic Web where software 
can access and reason about information on the Web is a key direction for 
military M&S work (Blais, 2004a). 

One item of concern within the XMSF concept is the issue of the timing of 
technological evolution and availability. The M&S focus group of the XMSF 
project has directed its energies into the two areas of refining technical issues 
and defining use cases which test the reach of the XMSF concept. The timelines 
set forth for these two areas define near term as 1 -2 years, mid term as 3-5 years 
and long term as greater than 5 years. Considering todays operational 
environment, solutions to XMSF problems/issues need to be geared towards 
“good enough” for near term implementation and fielding with continuing work 
towards perfecting solutions in the later time frames. Warfighters need workable 
solutions quickly rather than notionally perfect solutions 5 years from now. 

In summary, XMSF can be described as an evolutionary strategy toward 
advanced distributed simulation using open standards - in particular standards 
related to the web - complementary to the high level architecture (FILA) to reach 
the next level of this domain of distributed computing (Tolk and Pullen, 2003). 

C. FLEXIBLE ASYMMETRIC SIMULATION TECHNOLOGIES (FAST) 

TOOLBOX 

The Flexible Asymmetric Simulation Technologies (FAST) Toolbox is 

sponsored by the Defense Modeling and Simulation Office (DMSO). The original 

concept of a FAST Toolbox came from the Military Operations Other Than War 

(MOOTW) Toolbox concept of operations (CONORS) (Crain, 2002). The 

purpose of the CONORS is to provide a long-range vision for the development of 

modeling and simulation (M&S) capabilities that support the needs of the 

Warfighter for the planning and conduct of MOOTW. Additionally, the 

development of the MOOTW “M&S in a Rucksack” is intended to complement, 
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rather than compete with, current and planned U.S. Department of Defense 
(DoD) M&S MOOTW capabilities and developmental programs. Where possible 
and as appropriate, the MOOTW Toolbox is intended to incorporate and leverage 
other U.S governmental agencies, U.S non-governmental agencies, foreign 
governments, international non-governmental agencies and private 
organizational MOOTW M&S advances and efforts (Crain, 2002). 

The current FAST Toolbox project incorporates the Joint Conflict And 
Tactical Simulation (JCATS), the Diplomatic and Military Operations in a Non- 
Warfighting Domain (DIAMOND), the Unit Order of Battle Data Access Tool 
(UOB DAT), the Interim Static Stability Model (ISSM) and the Canadian Forces 
Land Mine Database (CFLD). This toolbox is meant to be rapidly deployable on 
a single laptop computer and used at the warfighting level for military planning 
and aiding course of action development and analysis. Recent work published 
for the Spring Simulation Interoperability Workshop extends the possibilities of 
the FAST Toolbox viewing it as an exemplar of the XMSF project based on a 
profile approach taking into account the Interoperability Profile, Implementation 
Profile and Security Profile of the project (Blais, 2004b). 

D. DATA INTEROPERABILITY AND DATA INTERCHANGE 

Recent research conducted by Capt James Neushul USMC, focused on 
the abilities of open source, non-proprietary driven software to afford military 
leaders the flexibility to not only visualize the battlespace using 3D visual 
graphics but also to communicate across the boundaries of platform 
dependencies and control their data using XML technologies (Neushul, 2003). 

An excerpt from a report coming from Iraq emphasizes his point. 

A Lessons Learned report from Operation Iraqi Freedom (OIF) 
describes an inability to effectively communicate battlespace 
geometry for planning due to software incompatibilities, and cited a 
lack of adequate National Imagery support during preparation or 
combat phases. These observations describe problems with 
access to dynamic data as it is generated on the battlefield, and 
static data that has been collected and archived so that 
commanders can put battlespace information in a visual geographic 
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context. There is a fundamental disconnect between the 
warfighter and the data that supports battlespace visualization 
(Neushul, 2003, 6). 

A common theme running through this work is the use of open-source 
software, non-proprietary data standards and service-oriented contracts so that 
military leadership can gain and maintain control over their information 
processing needs. Capt. Neushul’s research emphasizes multiple times that: 

Software must be required to be as adaptable and flexible as the 
individuals that use it. Demands must be made that force 
extensibility and Network-Centricity. Current practices of software 
licensing at the expense of data control must be rejected, and 
solutions that enable common visualization, and that incorporate 
information exchange data models must be adapted at all levels 
(Neushul, 2003, 17). 

Captain Neushul also discusses an extensibility paradigm that sounds 
much like one of the driving concepts behind the MDA, which is platform 
independence. The ability to develop applications that may be used regardless 
of the operating system or hardware platform on which they will be applied is a 
key to many ideas dealing with extensible web-based technology usage. Data 
control via XML Schema is addressed here and detailed examples are presented 
providing evidence of the validity of the arguments made. 

Battlefield visualization is also discussed and an example of how this can 
be accomplished using X3D (Web3D, 2004), GeoVRML (GeoVrmI, 2004) and 
Scalable Vector Graphics (SVG) (W3C, 2004), is provided, demonstrating the 
power of XSLT and the X3D language to transform binary elevation data into a 
graphically viewable format in a web browser. Because of his work, 3D views of 
standard Digital Terrain Elevation Data (DTED) (DTED, 2004), data are now 
available to authorized users with access to web browsers, and warfighters in all 
theatres have the ability to use this tool to examine terrain that they may need to 
control. 
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E. SCENARIO INTERCHANGE 

Many Navy efforts use the Naval Simulation System (NSS) (Naval 
Simulation System, 2004) as a force-on-force modeling and analysis tool. The 
original design intent of the NSS allowed NSS systems to communicate with one 
another while they were connected via a High Level Architecture (HLA) Run Time 
Infrastructure (RTI). This communication is done through the use of vendor- 
specific RTI application programming interfaces (API). Recent thesis work 
completed at the Naval Postgraduate School used the NSS to examine scenario 
interchange. The research demonstrated the ability to use XML to represent 
NSS scenario data so that NSS users could interchange scenario data amongst 
themselves and possibly other applications. The use of XSLT to transform 
scenario data into a textual format was also explored to enhance NSS 
capabilities (Hout, 2003). Central to this research is the desire to exchange data 
between NSS users and other applications using the host of XML technologies. 

F. ARMY TACTICAL COMMAND AND CONTROL INFORMATION 

SYSTEM (ATCCIS) 

“ATCCIS was founded in 1980 to see if interoperability could be obtained 
at reduced cost and developed according to technical standards agreed upon by 
multiple Nations and prescribed by NATO” (MIP, 2004). The objective of the 
Army Tactical Command and Control Information System (ATCCIS) (ATCCIS, 
2004) was and continues to be to investigate whether interoperability through the 
development of a set of minimum standards for information interchange can be 
achieved at a reduced cost and developed according to technical standards 
prescribed by the North Atlantic Treaty Organization (NATO) and its participating 
nations. The program’s goal was to identify a minimum set of specifications to be 
included within command and control (C2) systems, allowing interoperability 
between those systems. The ATCCIS program was not a formal NATO program, 
instead it was a voluntary and independent activity sponsored by the Supreme 
Headquarters Allied Powers Europe (SHAPE). 

The ATCCIS specification is a managed interface between C2 information 
systems. It encompasses two parts: a data model and a replication mechanism 
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called the ATCCIS Replication Mechanism (ARM). The ARMs function is to keep 
information up to date in cooperating systems whenever a C2 application 
changes the state of information it holds. The meaning and context of the 
information do not change and require no additional processing (NATO, 2002). 
When incorporated into a system, ATCCIS enables interoperability of information 
between other systems that also incorporate the same specification. The 
information exchange requirements, both horizontal and vertical, upon which 
ATCCIS is founded, encompass the spectrum of Joint and Combined Land 
Operations. ATCCIS has only one interface and is not concerned with the 
implementation or the display of any country C2 systems. As such, each 
country’s command and control systems may be wholly different from each other 
and do not have to conform to any hardware or software standard. The ATCCIS 
program was merged with the Multilateral Interoperability Program (MIP) in the 
early part of 2002. 

G. MULTILATERAL INTEROPERABILITY PROGRAM (MIP) 

The Multilateral Interoperability Program (MIP) (MIP, 2004), was 
established in 1998 as a merger of two other programs: the Battlefield 
Interoperability Program (BIP) and the Quadrilateral Interoperability Program 
(QIP). “The aim of the Multilateral Interoperability Programme (MIP) is to achieve 
international interoperability of Command and Control Information Systems 
(C2IS) at all levels from corps to battalion, or lowest appropriate level, in order to 
support multinational (including NATO), combined and joint operations and the 
advancement of digitization in the international arena.” (MIP, 2003, 5) In 2002 
the Army Tactical Command and Control System merged with MIP. ATCCIS and 
MIP’s parallel goals and development led to this natural merging. MIP is the 
custodian for the C2IEDM which is an extensible data model that provides a 
method for exchanging command and control data. 

H. COMMAND AND CONTROL INFORMATION EXCHANGE DATA 

MODEL (C2IEDM) 

The Command and Control Information Exchange Data Model (C2IEDM) 
is a product of the analysis of a wide spectrum of allied information exchange 
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requirements by 16 nations. It is one of two parts that made up the ATCCIS. It 
models the information that allied land component commanders need to 
exchange (both vertically and horizontally). It serves as the common interface 
specification for the exchange of essential battlespace information (NATO, 2002). 
The model was designed to achieve two separate but related goals, one of which 
is focused on in this thesis. That goal is to describe objects in the battlespace 
(objects for the purposes of this work are units). This description includes the 
characteristics of the objects, their status, their locations, their interrelationships, 
capabilities, addresses, and other properties. The second goal that will not be 
investigated here is the goal of describing activities of those objects in the 
battlespace. The ATCCIS ARM mentioned above complements the C2IEDM. 

The command and control information exchange data model’s primary 
purpose is the generic representation of command and control information. It is a 
data model. “The C2IEDM is a container document that captures the information 
and data modeling artifacts. This document is also used as a standard to support 
national implementations of C2 applications and supports national data 
management activities outside of the MIP.” (MIP, 2004c). Due to the extensive 
development of the model and complete documentation, many government 
organizations are currently moving towards using C2IEDM as their predominant 
data model. It comes as no surprise that the Department of Defense is one of 
those organizations. Figure 2 portrays the concept behind the MIP/C2IEDM 
project. 
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Figure 2. Concept of Information Transfer envisioned by the software 
developers at the Institute for Defense Analysis (IDA) (From Simaitis, 2004). 


The C2IEDM models command and control information that combined 
arms and joint combined commanders want and need to exchange through the 
use of an entity-relationship type model (MIP, 2003c). “C2IEDM is intended to 
represent the core of the data identified for exchange across multiple functional 
areas and multiple views of the requirements. Toward that end, it lays down a 
common approach to describing the information to be exchanged in a command 
and control (C2) environment” (MIP, 2003c, 12). Objects in C2IEDM are 
classified as either types or items. Figure 3 shows the OBJECT-ITEM and 
OBJECT-TYPE structures. Object-types and items are the building blocks of the 
model and are related through the OBJECT-ITEM-TYPE structure. Each 
contains entities that provide further detail to information being transmitted. 

Figure 4 provides a high level view of the C2IEDM model that includes some of 
the associations and entity relationships seen in the model. Figures 5 and 6 show 
the expanded OBJECT-TYPE and OBJECT-ITEM constructs from the model. 
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Figure 3. Core Kernel of C2IEDM containing OBJECT-TYPE, OBJECT-ITEM 
and OBJECT-ITEM-TYPE constructs. (From Johnson, 2004). 


1. Strengths of the Model 

The C2IEDM has a broad range of applicability which is further enhanced 
through the ability of adding national extensions. The models central concepts 
have been stable for 12 years. The documentation that speaks to these 
concepts is complete and detailed. The model has a multinational pedigree. 
Over 25 countries are currently represented within the MIP and are actively 
engaged in the development of the model for their country’s military use. The 
semantic content of the model can be enriched to suit the needs of any 
community of interest (COI). Lastly the model is relatively easy to extend in 
response to operational data requirements. Each participating nation within the 
MIP at some point has or may need to create extensions to support their 
warfighting doctrine and operational procedures. An example of a U.S. led 
extension being proposed to NATO is found in the area of Chemical, Biological, 
Radiological, and Nuclear (CBRN) messaging and operations. The US CBRN 
community of interest (COI) evaluated the C2IEDM and found it deficient for 
representing NBC data required for requisite NBC C2 systems (Johnson, 2004). 
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Figure 4. High level view of the C2IEDM model showing the many to many 
relationships between the different entities of the model (From Johnson, 2004). 


To address the models shortcomings for their community, they developed 
the CBRN Data Model as part of a larger CBRN Data Initiative. 

The mission of the data initiative is to promote the interoperability 
and reuse of CBRN Data across the Joint Warning and Reporting 
Network (JWARN), the Joint Effects Model (JEM), the Joint 
Operational Effects Federation (JOEF) programs and other CBRN 
programs. The primary goal is to eliminate interoperability failures 
by mapping current and legacy CBRN data to a common reference 
schema. The use of a data schema promotes data reuse and 
standardization. To ensure commonality with joint and coalition 
C4ISR systems the data schema begins with a subset of the NATO 
Command and Control Information Exchange Data Model 
(C2IEDM), adds in those data elements needed to fully describe 
CBRN information, and relates that information to the existing C4 
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data elements resident in the current version of the C2IEDM. This 
work will result in a common data schema that can be used by all 
CBRN applications that need to interface with joint and coalition C4 
systems including simulation systems (O’Keefe, 2003, 1-2). 

The CBRN Data Model data exchange standard offers a technologically 
sound structure for Multi-Service interoperability development across NBC 
specific domains. The extended structure may also allow non-NATO Coalition 
Interoperability within the current NATO security posture. 



Figure 5. OBJECT-TYPE relational tree found in the C2IEDM (From Johnson, 

2004). 
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Figure 6. OBJECT-ITEM relational tree found in the C2IEDM (From Johnson, 

2004). 

Thus extensions to C2IEDM have been successfully demonstrated. Figure 7 
shows a portion of the CBRN Data Model with showing two specific extended 
elements CBRN DETECTION and CBRN EVENT. Figure 8 shows the expanded 
CBRN EVENT namespace used within the CBRN Data Model. Additional 
elements of the CBRN Data Model can be seen in Figure 8. Figure 9 shows the 
level of detail that is possible in extensions to the C2IEDM. As with any model, 
extensions must follow the syntactic rules and conventions of that model. 

Figures 8 and 9 display several of the syntactic conventions used to describe 
CBRN data in the CBRN Data Model. Whether the CBRN Data Model will be 
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eventually accepted as a formal extension of the C2IEDM remains the object of 
continued work. 



Figure 7. Extended C2IEDM showing the CRBN event (From Johnson, 2004). 
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Figure 8. CRBN-EVENT construct of Extended C2IEDM showing additional 

detail (From Johnson, 2004). 
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CBRN-DETECTION 

cbrn-detection-id.action-event-id: NUMBER{15) (FK) 

cbrn-detection-location-id.location-id: NUMBER(15) (FK) 

sensor-id.materiel-id: NUMBER(15) (FK) 
cbrn-detection-sample-type-code: CHAR(6) 
cbrn-detection-type-code: CHAR{6) 

agent-type-id.consumable-materiel-type-id: NUMBER(15) (FK) 

deposition-contamination-quantity: NUMBER (12,3) 

inhalation-contam i nation-quantity: NUMBER(12,3) 

cbrn-detected-dose-quantity: NUMBER(12,3) 

cbrn-detected-dose-rate: NUMBER{13,4) 

deposition-concentration-quantity: NUMBER(12,3) 

inhalation-concentration-quantity: NUMBER{12,3) 

cbrn-detected-concentration-time-rate: NUMBER (13,4) 

cbrn-dose-rate-trend-code: CHAR (6) 

cbrn-actual-dec ay-rate: NUM BER(7,2) 

cbrn-relative-decay-rate-code: CHAR(6) 

cbrn-detection-datetime: DATE 

cbrn-generic-alarm-result-code: CHAR(6) 

cbrn-potential-harm-result-code: CHAR (6) 

cbrn-confirmation-test-code: CHAR(6) 

cbrn-results-assurance-level-code: CHAR(6) 

cbrn-detected-agent-purity-traction: NUMBER(6,5) 


CBRN-SCENARIO-DETAIL _ 

cbrn-scenario-id: NUMBER(15) (FK) 
cbrn-scenario-index: NUMBER(15) 

cbrn-event-id: NUMBER(15) (FK) 
•action-event-id: NUMBER(15) (FK) 
cbrn-detection-id: NUMBER(15) (FK) 

m J 


CBRN-EVENT • 

- 1 -^ 

cbrn-event-id.action-event-id; NUMBER(15) (FK) 

cbrn-event-category-code: CHAR(6) 

cbrn-event-subcategory-code: CHAR(6) 

cbrn-event-alarm-result-indicator-code; CHAR(6) 

cbrn-e vent-confirm at ion-test-indicator-code: CHAR(6) 

cbrn-event-start-datetime: DATE 

cbrn-event-end-datetime: DATE 

cbrn-event-occurrence-qualifier; CHAR(6) 

cbrn-event-type-code: CHAR(6) 

cbrn-e vent-deli very-mechanism-code: CHAR(6) 

burst-location-type-code: CHAR(6) 

cbrn-e vent-initial-size-diameter; NUMBER(12,3) 

cbrn-event-confirmed-location-id.location-id: NUMBER(15) (FK 


Figure 9. Expansion of several nodes of the CRBN C2IEDM extension (From 

Johnson, 2004). 


Further information and Instructions for requesting extensions to the 
C2IEDM can be found in (MIP, 2003a). 

2. Weaknesses of the Model 

For all of its strengths, the C2IEDM also has limitations. According to the 
Institute for Defense Analysis (IDA) the model is relatively simple and 
understandable (Simaitis, 2003). Depending on the background of the reader 
and the representation used this may not be the case. The current C2IEDM 
Version 6.1 schema provided by IDA is much easier to understand than the 
Battlespace Information Exchange Schema (BIXS) created by Capt. James 
Neushul representing the same data exchange model. One of the reasons for 
this is IDAs use of a database to hold all of the data elements in the model. This 
technique makes the IDA version’s structure much flatter and easier to traverse. 
This comes at a cost however. The use of a database creates problems for 
those developers who want the model absolutely exposed and extensible; i.e., in 
a human-readable, human-modifiable and document-centric structure. The 
document-centric version of the schema produced by Neushul uses only native 
XML to represent the data held within the model. Since the model contains many 
relationships, data in the BIXS must be replicated completely in many different 
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locations throughout the model. While the BIXS version of the C2IEDM is human 
readable, it is not necessarily understandable. Multiple representations of the 
data throughout the schema potentially confuse users if they are not familiar and 
comfortable with the C2IEDM itself. Future work suggests methods to help 
reduce some of the BIXS complexity. 

I. BATTLE MANAGEMENT LANGUAGE (BML) AND XBML 

The Battle Management Language (BML) (MSIAC, 2004) is defined as an 
“unambiguous language used to command and control forces and equipment 
conducting military operations and to provide for situational awareness and a 
shared, common operational picture” (Tolk and Pullen, 2003, 10). BML is 
intended for use in exchanging command and control information between 
individuals using C2 systems, simulations and future robotic forces. Four 
principles have guided the development of BML. The first is that BML must not 
be ambiguous. Second, it must not constrain the military commander’s intent 
within the limits of the military operational domain. Third, it must use and be 
compatible with existing C3I systems. Finally, it must allow all systems and 
participants to communicate information about themselves, their mission, and 
their environment in order to create situational awareness and a shared, common 
operational picture. BML also supports data consistency by checking the data 
used in simulation initialization, decision support and the recommended courses 
of action that are derived from iterative simulation runs using the actual 
operational context. 

Currently the most widely used format for military communications is free 
text. The reason for this is that the underlying vocabularies are defined in the 
doctrinal manuals. Flowever a difficulty with using free text is that to be 
understood the context in which the text is used must be clear. This is not 
always the case. Current messaging context, whether in the form of operations 
orders, fragmentary orders or warning orders, depends on the backgrounds of 
the sender and receiver, the operational context, and the branch of service of 
both the sender and receiver. In terms of information processing, machines do 
not do well with ambiguity. For this reason an XML Repository was added to the 
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BML development process to capture the harmonized results of mixing doctrinal 
manuals (semantic content) and C3I data models to check the consistency of 
messages, orders, courses of action, scenarios, and other context sensitive 
military information. 

XBML is an XML version of BML that can be utilized as a web service via 
XML/SOAP and C2IEDM. The following is a list of supporting technologies for 
the project: 

. XMSF 

. C2IEDM 

• Structured Representation of Doctrine 

• Doctrinal Definitions and Task Lists: Joint Level Definitions and Task 
Lists; e.g. Joint Pub 1-02 Dictionary of Terms and Universal Joint Task 
List (UJTL) 

• Service Definitions and Dictionaries; e.g., FM 101-5-1 Operational Terms 
and Graphics 

• Service Task Lists; e.g. FM 7- 15, The Army Universal Task List (AUTL) 
(Hieb, 2003). 

The XBML project is currently focusing on taking an existing Army BML 
testbed and using Simple Object Access Protocol (SOAP) /XML interfaces to 
develop a demonstration of XBML’s utility. The goal is to develop a testbed for 
“plugging in” C4I and simulation systems (see Figure 10) (Flieb, 2003). Ongoing 
work includes harmonizing BML semantic constructs with the C2IEDM data 
model. 
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Figure 10. Pictorial representation of the XBML Testbed (From Fleib, 2003). 

LEGEND: 


BML Battle Management Language 

GUI Graphical User Interface 

0TB OneSAF Testbed 

SOAP Simple Object Access Protocol 

CAPES Combined Arms Planning and Execution System 
J. TOPTIVA 

The Theater Anti-Submarine Warfare Combat System (TASWCS) 
Operational Task (OPTASK) Interactive Viewing Application (TOPTIVA) is a 
command and control application that exposes the functional areas of the MIP 
C2IEDM project (Brutzman, 2004). The TOPTIVA application was developed at 
the Naval Undersea Warfare Center (NUWC) Newport Rl and uses the C2IEDM 

as the data exchange format for tactical operational information via the 
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Operational Context exchange Service (OCXS). This service is an XML 
messaging service that has also been developed by NUWC. TOPTIVA contains 
a graphical user interface (GUI) that allows users to visualize orders that have 
been transmitted via the OCXS messaging service. Figure 11 shows a snapshot 
of TOPTIVAs OpenMap™ presentation layer. 



Figure 11. OpenMap™ screen shot from TOPTIVA which uses the C2IEDM 

data model. 

In its current state TOPTIVA only incorporates a small fraction of the total 
C2IEDM. Work continues to fully develop this technology so that it may be 
incorporated into more submarine combat control system (CCS) simulation 
exercises as well as other virtual battle experiments for the U.S. Navy. 

K. SUMMARY 

This chapter has reviewed several pieces of research geared towards 

increasing the military’s ability to exchange data within the C2 and simulation 
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communities of interest. It has reviewed the current issues dealing with the lack 
of integration and extensibility of current systems and solutions to these 
problems using XML technologies and extensible frameworks. XML is the 
prevailing technology in most applications and areas where the qualities of 
extensibility, openness and integration are necessary. Most of the examples 
discussed in this chapter focus heavily on the necessary ability to interchange 
information between applications and amongst new and existing systems. This 
focus is prevalent throughout the DoD as it has become readily apparent that the 
current stovepiped methodology of system development with a later desire for 
integration and interoperability is no longer acceptable. All of the efforts 
discussed in this chapter are attempting to harness existing technologies for the 
enhancement of the nation’s warfighting and defense capabilities. 
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III. MODEL DRIVEN ARCHITECTURE (MDA) 


A. INTRODUCTION 

This chapter discusses the Model Driven Architecture (MDA). MDA is a 
software development methodology that predicates itself on using models and 
modeling software to autogenerate computer code for processes that require 
complete documentation and that are easily updatable. The MDA is examined 
for its potential use in assisting to solve data interchange difficulties. 

B. MDA DEFINITION 

The Object Management Group’s (OMG) Model Driven Architecture 
(MDA) provides an approach for designing and building component based 
systems that remain decoupled from the languages, platforms and middleware 
environments that are eventually used in the implementation of those systems. A 
key characteristic of the MDA process is the ability of an organization to be able 
to model their systems once and then transition them over time as standards and 
infrastructure technologies become more mature (Parr and Keith-Magee, 2003). 

The essence of MDA is that the criterion of executable software 
architecture should be driven by the formulation of models rather 
than by manually writing source code. Source code is generated 
from the models by a compilation step much as machine code is 
generated from source code. The MDA initiative aims to move 
software development to a higher level of abstraction (Arlow and 
Neustadt, 2003, 50) 

The MDA concept has evolved from the need to build solutions for 
widespread software-development computing problems in business. It is a 
simple concept to explain yet much more difficult to employ, since the 
technologies necessary to realize MDA concept have not been fully developed 
and implemented. Prior to code implementation, a development cycle is followed 
to make the concept of an application a reality. This development cycle 
sometimes follows a waterfall model, sometimes not, but generally is an iterative 
process that includes feedback from the client for whom the application is being 
developed. Traditionally, during the design phase, high-level models are created 
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on paper, white boards etc. to describe the concepts and functionalities required 
and necessary for the application. 

A common complaint in software design and development is the lack of 
detailed documentation accompanying developed software. Many programmers 
believe that their only job is to write the code implementing a solution to a 
particular problem they have been given. They believe that it is someone else’s 
responsibility to compile the documentation necessary for the purposes of 
understanding the development process, the potential problems and the 
requirements for upgrading or maintaining the application software. A second 
complaint during this design phase is that a lot of work has been done to develop 
a model of the application but no progress is made on writing the code to 
implement the solution. Often developers want to skip this part of the process 
because they feel that they are wasting their time. They know that the models 
and documentation developed in this stage are useful but that they will be out of 
date and relatively useless once the project is complete. 

MDA is an attempt to correct this trend. Its goals are to use and develop if 

necessary the graphical modeling tools needed in the design process and to 

make them more robust so that they actually do more than just graphically 

represent the application under development. During the implementation of the 

MDA process different models come into existence. In keeping with current 

trends of extensibility, MDA is driven to use concepts and tools that will allow 

extensibility. To do this, the MDA is designed to first develop a platform- 

independent model (PIM) that abstractly reflects the application. The modeling 

tool used to create this model includes functionality to create the computer 

software to fully implement this model. An important point is that the Object 

Management Group (OMG) considers source code to be a valid model since it is 

a formal specification that has a distinct semantic meaning and models 

executable machine code that is developed through the use of an interpreter and 

compiler (Arlow and Neustadt, 2003). Once PIM development is complete, a 

transformation process is used on this model which generates subsequent 

platform-specific models (PSMs). These PSMs are tailored to the platform on 
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which they will operate. Again during a transformation process, the modeling tool 
generates the computer software necessary for the model to run on that 
particular platform. This platform-specific model then undergoes a 
transformation that generates application software. 

In addition to the models and software to run the application, software that 
adds functionality between like and unlike systems is created during the 
transformational processes. This software acts as and is called a bridge. Since 
the information is present for each of the models to know what is required of 
them, it is possible to generate specific bridges to connect the different platforms. 
C. MDA STRUCTURE 

1. Platform-Independent Model (PIM) 

This is the high level model created during the design process which takes 
into account all of the functionality of the application under development. This 
model is based on a high level of abstraction and is focused towards the best 
solution to the problem at hand. This model has no ties to operating systems or 
other proprietary software or system. PIMs are the most abstract of the 
architecture models and are the most valuable. 

2. Platform-Specific Models (PSM) 

These models directly result from the platform independent model. “A 
PSM is tailored to specify your system in terms of the implementation constructs 
that are available in one specific implementation technology” (Kleppe, 2003). 
They contain both business and platform information, are created by mapping the 
PIM to a particular platform stack, are detailed models using Unified Modeling 
Language (UML), and are the basis of source code and associated artifacts 
(Arlow and Neustadt, 2003). PSMs are less abstract than PIMs and are used to 
generate source code, which in turn is the least abstract feature of the MDA. 

3. Source Code 

Source code is generated in one of two ways. It is manually generated by 
the application programmer or it is generated through the modeling tool, an 

example of which is executable UML. Source code is the least abstract model in 
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the MDA process but it is considered by the OMG to be a model since it 
represents machine language. 



Figure 12. Steps in MDA development Process (From Kleppe and others, 

2003). 


D. USING MDA FOR DATA MODELING 

The original thesis intent is depicted in Figure 13. The goal there was to 
use the UOB version 7.7 schema as the target structure, populated with data 
extracted from the Battlefield Information Exchange schema (BIXS). The BIXS 
acts as the PIM and the UOB acts as the first in a series of PSMs. Once the unit 
information was formatted correctly using the UOB structure it could be further 
transformed, using XSLT, into other PSMs usable within the FAST Toolbox such 
as JCATS and DIAMOND. This concept was originally supported by such 
statements as 

Models suitable for use in the MDA have to be written in a well- 
defined language (Kleppe, 2003) which XML is and that in reality it 
is difficult to draw the line between platform independent and 
platform specific. Is a model written in UML specific for the Java 
platform because one of the class diagrams defines one or more 
interfaces? Is a model that describes the interactions of 
components specific for a certain platform only because some of 
the components are ‘legacy’ components, which may be written in, 
let’s say, COBOL? It is hard to tell (Kleppe, 2003, 22). 

Using XML and XSLT to conduct the required modeling appears to work 
in the abstract, but there are concerns that this idea may not necessarily conform 
to the intent of the MDA. 
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Schema Modeling 

Currently Exists Using MDA 



indicate “validates” 

Figure 13. Original thesis model utilizing MDA concepts. 

Since the OMG stated that code is itself a model, all of the data modeling 
necessary for this work could be represented using XML. XML is a meta markup 
language which can be applied to design other languages used to provide 
structure to text documents which makes them well defined. However, XML is 
also considered a type of implementation, so its use as part of the PIM may 
violate the MDA intent, although the modeling language is not the real issue, 
expressing the abstract model is. It can be argued that C2IEDM is a specific 
implementation as well. A PSM represents a specific application instead of a 
specific language used to develop an application. From this perspective, JCATS 
and DIAMOND are PSMs. 

The use of XSLT for transforming data models parallels the MDA 
transformation process. However as discussed previously, the differentiation of 
what constitutes a PSM or PIM depends on the developer’s point of view. For 
data modeling, there is a one-to-one mapping of the concepts from MDA to XML 
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based technologies. However, UML is the prevailing modeling language 
specifically extensible UML, mentioned in the MDA literature that is necessary to 
make MDA fully functional. Other technologies were introduced such as the 
Extensible Metadata Interchange (XMI) and Enterprise Java Beans (EJB) but it 
was apparent that since the OMG is the developer and custodian to the UML, it is 
the tool recommended for successful implementation of the MDA. 

E. NEXT STEPS 

While using MDA may be the method some businesses will attempt to use 
for the development of their software applications in the future it appears that 
MDA is not yet the best method in the context of this thesis. Several limitations 
of the MDA of note follow. First MDA is software centric even though the OMG 
desires it not to be and it is focused on an application’s architecture. Secondly, 
the tools to fully implement the MDA are promising but are still emerging and 
generally speaking are too advanced for the average user. Third, reworking 
legacy systems so that they fall into the architecture is not only difficult but 
prohibitively expensive. 

Generally, the intent of the MDA is sound but the necessity to be an expert 
using only certain tools to implement the architecture is not. It is not clear how 
technologies like XML and XSLT fit within the MDA. Further maturity in MDA 
software tools and greater availability of well-adopted examples may eventually 
change this situation. Rearchitecting large numbers of diverse legacy software 
systems is not a practical approach. Instead, this thesis looks at correlating 
tactical data models, so that XML-based documents and message interchange 
might achieve broad interoperability in daily practice. 
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IV. UNIT ORDER OF BATTLE (UOB) TOOLSET 


A. INTRODUCTION 

This chapter introduces the Unit Order of Battle (UOB) Toolset and its 
component parts, the data sources found within UOB, the Data Access Tool 
(DAT)used to extract information from the databases and the Data Interchange 
Format (DIF) used. The UOB is an authoritative source for unit order of battle 
information due to its completeness and relative ease of use. Additional 
information about the UOB and instructions for downloading the tool may be 
found are discussed in (UOB, 2004). 

Before proceeding, two questions need to be answered. First, what 
comprises a complete unit description? This question must take into 
consideration both DoD and NATO/coalition forces if it is to be complete. 
Normally, Order of Battle (OOB) consists of identification, strength, command 
structure, and disposition of the personnel, units, and equipment of any military 
force (Flout, 2003). Secondly, where might the information be located? Several 
data sources currently exist that contain unit information. The answers to both of 
these questions appear to be located within the UOB Toolset located within the 
FAST Toolbox. 

DMSO’s Data Engineering program sponsors the UOB Toolset. The 
project was put together to address the problem of too many unit order of battle 
sources with overlapping and sometimes inconsistent data. The UOB Toolset is 
the most acceptable source of unit order of battle comprised to date. 

B. UOB TOOLSET 

The Unit Order of Battle (UOB) Toolset consists of three main 
components: a library of UOB data sources, a data access tool (DAT), and a data 
interchange format (DIF). Figure 14 depicts the UOB DATs major components 
and pictorially represents their interactions. 
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UOB DAT’s Three Major Components 

users 



UOB DIF 


unit OB Authoritative Sources 


Force Stmeture 8 Analysis 
Operaional Plan Development 
Analysis & Training 
Test & Evaluation 
Professional 
Military Education 

Knowledge Acquisition 

• select r>/n 

• extract 

• edit/save 


Access Tool to Task Organize & 
Produce TOs in Standard Format 


1. Authoritative UOB Data Sources 


2. UOB Data Access Tool (DAT) 


3. UOB Data Interchange Format (DIF) 


Figure 14. The UOB Toolset Components (From Cipparone and Hopkins, 

2003) 


1. UOB Data Sources 

As was mentioned earlier, UOB data is available from a variety of sources. 
These include both U.S. and non-U.S. forces at UNCLASSIFIED and SECRET 
classification levels. DMSO's Authoritative Data Sources project has identified 
several sources of UOB data (Hopkins, 1999). Currently, the UOB Toolset 
provides access to a significant number of these data sources. Organizations 
owning units maintain the UOB source data and provide them in their native 
formats to the maximum extent possible. To address the need for authoritative 
classified UOB data, the Toolset provides access to the following classified 
resources. 
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• Conventional Forces Database (CFDB) - The CFDB was created by US 
Central Command (CENTCOM) under the sponsorship of the Joint Staff 
(JS) J8’s Modern Aids to Planning Program (MAPP) and contains current 
data about US Army, Navy, Air Force, and Marine units, personnel, and 
equipment from many sources. The CFDB is updated twice a year and is 
distributed by the Office of Defense (OD) Program, Analysis, & Evaluation 
(PA&E). The database is classified as SECRET. 

• Global Status of Resources and Training System (GSORTS) and the 
Global Command and Control System (GCCS) - two authoritative 
operational data sources for US Army, Navy, Air Force, and Marine units, 
personnel, and equipment. These two sources are classified SECRET. 

• Modernized Integrated Database (MIDB) - MIDB, created by the Defense 
Intelligence Agency (DIA), contains general military intelligence data on 
many foreign facilities, units, personnel, equipment and targets. The MIDB 
database is classified SECRET. 

• ForceGen - created by the National Ground Intelligence Center (NGIC). 
ForceGen is an Authoritative Data Source (ADS) of information and 
contains eighteen countries UOB data with projections ahead for twenty 
years. This database is classified SECRET. 

• Conventional Forces Europe (CFE) - The CFE contains U.S. Units 
located in Europe and forces of other countries in Europe that are 
members of the arms control agreements. This database is unclassified 
but only available on the SIPRnet and DMSO’s MOOTW tool kit. 


To address the need for unclassified data, the Toolset also provides access to: 

• Unclassified ForceGEN - Contains non-U.S. forces, maintained by the 
NGIC. The database contains both a heavy and light force structure. 
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• Army MTOE -This database contains all Army Units with their authorized 
and required personnel and equipment data. There are two versions of 
this source: one that provides unit information down to the Company level 
and one that provides unit information down to the lowest Army 
organizational level, usually the team level. This database is maintained 
by U.S. Army Force Management System Agency (USAFMSA). 

• Generic U.S. units - This is an extract from the Type Unit Cargo 
Characteristics (TUCFIA) Joint Operations, Planning and Execution 
System (JOPES) reference file. 

• Non-Governmental Organizations (NGOs) - This consists of selective 
approximations of Non-Governmental Organizations (NGO), Private 
Volunteer Organizations (PVO), and International Organizations (10) that 
have been constructed and added to the database for use with 
applications concerned with MOOTW. 

• Characteristics and Performance (C&P) data - A link has also been 
created between significant unit equipment and the SPIRIT and JANES 
C&P databases. 

In the future, DMSO plans to expand the UOB data available via the 
Toolset by including future year projected data for U.S. Army units from Total 
Army Equipment Distribution Program (TAEDP) and the DIA National Futures 
Database (NFDB) (Cipparone and Flopkins, 2003). 

2. UOB Data Access Tool (DAT) 

The UOB DAT provides access to the UOB data sources identified above 

and the ability to manipulate UOB data to serve specific application 

requirements. The DAT is a tool using both server and client relationships in a 

virtual data warehouse architecture. Only the client Data Access Tool and any 

UOB data the user chooses to save locally are resident at the user's site. The 

authoritative UOB data server is resident at the data producer's location and is 

accessible by the client DAT across the public Internet (for unclassified data) or 

the SIPRNET (for classified data). This architecture ensures that UOB DAT users 
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are accessing the most currently available data from the authoritative sources. It 
also alleviates the need to replicate and maintain UOB data storage at each 
user's site. The producers of the authoritative data are responsible for storing 
and maintaining the data. The data access tool features a graphical user 


interface depicted in Figure 15, which allows users to retrieve and browse unit 
order of battle data and associated information and select individual units easily 


and quickly across distributed networks. 


UOBDAT Client 


gj^pil nr |4r| 1 |i^ 




File View Window Help 



Figure 15. The UOB DAT Main Browser/Editor Screen. 


3. UOB Data Interchange Format (DIF) 

The UOB DIF is the last, critical component of the UOB Toolset 
established by DMSO. By utilizing this single format, M&S developers have 
access to data from a variety of UOB data sources. This interchange format 


39 
































































eliminates the need to develop an understanding of each UOB data source's 
format and the need to write interfaces unique to each data source. The UOB 
DIF is based on data element standards submitted to the DoD Data 
Standardization Program and encompasses the key information elements 
common to the authoritative data sources enumerated above. Logically, the 
UOB DIF is comprised of five interrelated sets of information: 

1. Identification of units and their organizational hierarchy. 

2. Aircraft associated with units. 

3. Personnel associated with units. 

4. Equipment associated with units. 

5. Aircraft / equipment characteristics and performance data. 

The UOB DIF has implemented four of the above items as either ASCII comma 
delimited or fixed width files. A portion of the UOB DIF data model is shown in 
Figure 16. 


UNIT 


U n it-1 d e ntif i cati o n- C o d e 


Unit-Name 

Parent-Unit-Identification-Code (FK) 

Present-Latitude 

P rese nt- Lo n g itu d e 

Present-Name 

Home-Latitude 

Home-Longitude 

Home-Name 

Unit-Type-Code 

U n it- D escri pti o n- C o d e 

P e rso n n e I-Auth o rize d 

Personnel-On-Hand 

Ship-Catagory 

Ship-Cate gory-Name 

Ship-Class 

Ship-Hull-Number 

Country-Code 

Unit-Data-Source 




is assigned / 
is assig n ed t o 


is assigned / 


is assigned to 


has operational conrol of/ 
is under operational control of 


is assigned / 
is assigned to 


UNIT-PERSONNEL 


Unit-Identification-Code (FK) 
Grade 

Military-Occupation-Specialty 


Personnel-Description 
Personnel-Quantity-Required 
P e rso n n e I-Q u a ntity-Auth o rize d 
Personnel-Qua ntity- O n- H a n d 
Personnel-Data-Source 


UNIT-EQUIPMENT 


Unit-Identification-Code (FK) ^ 

Equipm 

ent-Code 

Equipm 

ent-Description 

Equipm 

ent-Quantity-Required 

Equipm 

e nt- Q u a ntity-Auth o rize d 

Equipm 

e nt- Q u a ntity- O n- H a n d 

Equipm 

ent-Data-Source 




UNIT-AIRCRAFT 


Unit-Identification-Code (FK) 
Aircraft-Code 


Ai rcraft- D escri pti o n 
Aircraft-Quantity-Required 
Ai rcraft- Qua ntity-Auth o rize d 
Ai rcraft- Qua ntity- O n- H a n d 
Ai rcraft- D ata- S o u rce 


Figure 16. Pictorial representation of part of the UOB Data Model (From 

Cipparone and Flopkins, 2003). 
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The logical and well-structured format of the UOB Toolset allows users of 
military unit data to tailor the data to fit the needs of their models and simulations. 
The UOB schema that describes the structure of an extracted UOB file is the 
guiding structure target used during the document development in this work. 

C. SUMMARY 

The UOB consists of three main parts: a Data Access Tool (DAT), a Data 
Interchange Format (DIF), and several databases. The databases comprise a 
complete and thorough compilation of classified, unclassified, U.S. and Foreign 
military unit information that is accessible using the DAT. The DAT allows users 
to manipulate unit information though the use of an intuitive graphical user 
interface. The DIF, based on standards developed for the DoD Standardization 
Program, holds the key information elements common to the authoritative data 
sources held within the UOB. 
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V. UNIT DATA TRANSFORMATION 


A. INTRODUCTION 

Chapter V addresses the transformation of unit data extracted from the 
BIXS C2IEDM using XSLT. This chapter provides an exemplar showing the 
power of XSLT to transform the data extracted from the BIXS C2IEDM into the 
format governed by the UOB version 7.7 schema. Appendix A contains the UOB 
schema. Appendix B contains the extracted UOB unit file which provides an 
example of what the result document may look like after the transformational 
process. Based on the conventions used in a schema, Appendix C is the XSLT 
stylesheet written to conduct the transformation. Appendix D is the result 
document from the XSLT transformation. Appendix E is the schema developed 
by the author prior to his ability to extract files from the UOB and Appendix F is 
the result document developed by the Author that validates against Appendix D. 

It should be noted here that several documents may be compliant with the same 
schema but may not look exactly alike. The reader will notice subtle differences 
between the extracted UOB file and the XSLT result document. Both documents 
are UOB schema compliant. 

B. XML SCHEMA DEFINED, DISCUSSED AND COMPARED 

What is an XML schema? “An XML schema is any type of model 
document that defines the structure of something” (Hunter and others, 2003, 

217). Perhaps a better way to look at it in the context of this effort is that a 
schema defines an XML tagset according to the W3C XML Schema 
recommendation. This work focuses on an XML document describing a military 
unit. XML Schemas are themselves XML documents, so they use the XML 
syntax and support XML Namespaces. Namespaces allow the combining of 
elements from different XML Schemas. They provide a method for development 
of ontologies by allowing several elements with the same name but from different 
XML languages to be used in a single document. Elements are differentiated 
from one another based upon their assigned namespace. 
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XML Schemas contain data types that can be either simple or complex. 
These allow developers to control the content of conforming documents more 
rigidly. When describing an element in a schema as a complex type that element 
may contain other elements, attributes, or both. Sometimes when designing 
XML Schema, we need to design our own data types. To do this, we may use 
either complex or simple type definitions. Simple type definitions use an existing 
data type in the XML language as their base or another user-defined data type. 
Simple type definitions are sometimes called derived types (Hunter and others, 
2003). 

All XML documents must start with a root element, and since XML 
Schema are a specific type of XML document they have a specific root element. 
For most XML Schema the word schema is the root element and to ensure 
uniqueness the namespace prefix xsd is commonly used. Generally, after the 
root element of the schema, the root element of the document is identified. To 
develop a schema, it is important to first know what the result document needs to 
look like. Appendix B shows what the result document may look like here. As 
was mentioned in the introduction, schema allow for flexibility in what the result 
document looks like that validates against them. This design decision allows for 
information, albeit sometimes incomplete, to still be of some use to the 
application. 

Appendix A provides the governing structure for the result document. The 
ability to extract information from the UOB databases in XML format eliminates 
the need to develop a result document by hand. Initial failed attempts at 
extracting information from the UOB database resulted in the author’s 
development of a schema and result document which closely resembles the ones 
extracted from the UOB version 7.7. While the schema and result documents 
are similar, several important differences exist. These differences are discussed 
now. 
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1. Schema Compared 

Any document to be validated against the author’s schema found in 
Appendix E must have a root element called unitData . From there the 
schema defines the structure of the result document beginning with the 
administrative data of the unit. Both complex and simple types of definitions are 
necessary to describe the information using the XML language. The author’s 
schema provides an outer structure for the document by using one all- 
encompassing complex type definition. This definition includes multiple elements 
that make up the rest of the structure. Figure 17 shows a portion of this 
structure. Two of the elements inside the complex type definition require the use 
of additional simple type definitions. In Figure 17 only the simple type definition 
for the unitLeveiCode element is shown. 

These simple type definitions are required because enumerated lists are 
necessary to describe all of the valid data values that may occupy the element in 
this XML document. They restrict the element data in the document to be of 
base string and then use the xs: enumeration element in the schema to 
elaborate on the exact items allowed inside this element in the result document. 
This accomplishes two things. First it prevents incorrect information from being 
accepted in the result document (no undefined enumeration strings are allowed). 
Second, it assists the document’s author to see exactly what data is considered 
acceptable in these elements. The remaining elements inside the complex type 
definition allow plain strings and are not as restrictive to the nature of what these 
strings must say. Compared to the UOB version 7.7 schema in Appendix A, the 
author’s schema is much more restrictive. This is an example of where a 
developer under time constraints has the flexibility to be lenient as to what he 
allows to be accepted as valid XML content. Time permitting either 
enumerations or simple type definitions using patterns and other built-in XML 
data types might replace these simple strings to provide even more stringent 
control of the information in the XML document. 

After the administrative data, information about the unit’s personnel is 

expected. For this another complex type element named Personnel is used 
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and required in the XML document. It contains the definition for the elements 
containing information about job descriptions, military ranks, military occupational 
specialties, numbers authorized, numbers on hand, etc. Again, enumerated lists 
and simple type definitions are used to best describe this data. The simple type 
definition used here is different however. This time the built-in data type called 
pattern is used. This data type allows the document author to specify the 
exact string pattern in terms of letters, numbers etc. allowed inside the element. 
Figure 18 shows the portion of the author’s schema that uses the pattern data 
type for defining the content of the MilitaryOccupationSpecialityCode 
element. 


Example simpleType 


Example enumeration 


<xs:element name="AdministrativeUnitlnformation"> 
<xs:complexType> 

<xs:sequence> 

<xs:element name=''ParentUIC" type=”xs:string"/> 
<xs:element name=''ParentUTC" type="xs:string"/> 
<xs:element name=''ParentULC'' type=''xs:string7> 
<xs:element name=”SRC” type="xs:string"/> 
<xs:element name=”UnitUIC" type=''xs:string7> 
<xs:element name=''UnitName" type="xs:string7> 
<xs:element name=''UnitTypeCode'’ type="xs:string7> 
<xs:element name="UnitLevelCode''> 
<xs:simpleType> 

<xs:restriction base="xs:string"> 
<xs:enunneration value="SEC7> 
<xs:enumeration value="SQD7> 
<xs:enumeration value="PLT7> 
<xs:enumeration value="HFT7> 
<xs:enumeration value="TRP7> 
<xs:enumeration value="C07> 
<xs:enumeration value="SQ7> 
<xs:enumeration value="BN7> 
xs:enumeration value="REG7> 
<xs:enumeration value="BDE7> 
<xs:enumeration value="DIV"/> 
<xs:enumeration value="CPS7> 
<xs:enumeration value="A7> 
</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 



Figure 17. Example enumeration used to specifically define what is allowed 
within the unitLeveiCode element of the 

AdministrativeUnitInformation element. 
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<xs:element name="MilitaryOccupationSpecialityCode"> 

<xs:simpleType> 

<xs: restriction base="xs :stri ng''> 

<xs:pattern value="[0-9]{2}[A-Z]{1}{[0-9]{2}|[0-9]{1}[A-Z]{1})7> 
</xs:restriction> 

</xs:simpleType> 

</xs:element> 


Figure 18. An example of the XML pattern data type in use. 

The pattern structure seen above allows for the first two digits of the 
pattern to be numbers between zero and nine. The next digit has to be one letter 
from A-Z. The third and fourth digits are two more numbers from zero through 
nine or can be just one number between zero and nine and one letter between A 
and Z. This is much different from the conventions used in the UOB schema. 

The UOB schema is not this restrictive and simply allows any string to be used 
inside this element. The loose structure of the UOB version 7.7 schema invites 
difficulties when it uses the less restrictive data types. 

In order to restrict anyone from filling in “none” as a valid value for the 
three elements of number authorized, on hand, and required, the element 
content is restricted to a type of non-negative integer (see Figure 19). In XML, 
this indicates that the numbers 0 through 9 are completely acceptable but no 
negative numbers are allowed and because the data must be a number, the input 
of strings will cause an error during XML validation, such as: “This file is not valid: 
Invalid value for database type nonNegativeInteger in element ‘numberRequired’” 
(generated by XMLSPY Enterprise Edition). 


<xs:element name="NumberRequired'' type="xs:nonNegativelnteger"/> 
<xs:element name="NumberAuthorized" type=”xs:nonNegativelnteger7> 
<xs:element name="NumberOnHand'' type="xs:nonNegativelnteger7> 


Figure 19. Example Non-negative Integer type use in Appendix E. 

The last piece of XML Schema developed by the author (Appendix E) 
involves the unit equipment. The unit equipment element is a complex type 
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element and includes those fields listed in the equipment file from UOB DAT. 

The use of the pattern data type again assists in ensuring that the equipment 
codes are in the correct format. Non-negative integers in the other elements of 
the complex type ensure no improper string usage. Once this step is complete, 
the schema is complete and it is then checked to ensure that it is well-formed, 
xml valid and XML Schema valid using the XML authoring tool XMLSPY by 
Altova. 

2. Document Development 

Given a complete schema an author has numerous software-tool options 
for generating a new XML document. Outside of trivial examples, authors will 
generally use software to generate data files. Some XML authoring tools can 
auto generate example documents if valid schemas exist. Generated documents 
can be useful to developers for revealing flaws in a schema. Autogeneration also 
saves time. When used, the document author simply is required to fill in the 
content of his document. This research effort used both approaches. XMLSPY 
generated one document, which was used to check the author’s design idea for 
Appendix E. This uncovered several problems namely in the authors use of 
patterns and enumerated lists. 

Although the structure of the schema in Appendix E was inspired by the 
UOB DAT, it is a more rigidly structured document than the UOB version 7.7 
schema provided in Appendix A. The reader should notice that although the 
Unit.xsd file does not fully encompass all NATO country-specific information it 
does enforce more rigid standards for things such as equipment and MOS codes. 
The more rigid structure ensures that the data being passed is in the correct 
format which creates a more stable environment. The permissive use of invalid 
strings for information may allow incorrect or false information to be accepted into 
an application, subsequently causing false outcomes or (even worse) fatal errors 
during execution. Such mission-critical errors are avoidable through careful 
schema design. 
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C. XSLT DOCUMENT DEVELOPMENT 
1. General Information 

Using XSLT to transform XML documents is a powerful and difficult 
endeavor. The reason for this is clear. We are attempting to take a source 
document with specific information governed by one schema, and precisely 
transform it into a generic form of the same data governed by a much different 
schema, in such a way as to allow different applications to use the corresponding 
data with consistent semantics. Many transformations may be necessary for 
legacy models and simulations but if a standard method and model of 
representation (i.e. ontology) are established then future models and simulations 
are likely to have less difficulty interchanging data. 

XSLT stands for Extensible Stylesheet Language for Transformations 
(Kay, 2003). It is another language in the growing family of XML languages used 
in this case to transform one type of XML document into another. XSLT is not 
just for producing other XML documents. It also can be used to generate HTML 
and databases of different sorts from an XML document. It has the ability to 
transform XML documents into other XML documents and to transform XML into 
plain text. It cannot, however, transform plain text into XML. XSLT uses a two 
stage approach to transform XML documents. 

The first stage is a structural transformation, in which the data is 
converted from the structure of the incoming XML document to a 
structure that reflects the desired output. The second stage is 
formatting, in which the new structure is output in the required 
format such as HTML or PDF (Kay, 2003, 14). 

XML and XSLT use an abstract data structure called a tree to represent 
document content. Source trees are formed from the initial XML document 
through parsing and result trees are formed by the XSLT parser through 
serialization. As a result of the use of trees, there is no single API or data 
representation of the contents of the tree, only a conceptual model that defines 
the objects in the tree, their properties and their relationships to one another 
(Kay, 2003). When referring to the result tree, reference is being made to the 
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structure and content rather than format. Reference to the result document 
indicates that the result tree is in the form of an XML document or other readable 
document form specified. Two methods of structuring data in the result tree are 
through the use of built-in templates or through the use of user developed 
templates. In the XSLT language, the xsi: template element defines a 
template rule. This rule is triggered when a matching portion of the source XML 
document is processed by the XML parser. The “match” attribute of the 
xsi: template element identifies a pattern to be used from the source 
document node tree. 

To begin any transformation process a template must typically be applied 
to the root node of the source document. The root element is identified by setting 
the match attribute equal to the forward slash character (/). If the XSLT parser 
does not find this explicit statement, it will use a built-in template to handle this 
situation. Templates consist of elements and text nodes. Elements in the 
template may either be classified as instructions or data depending on their 
namespace. When a template is instantiated the instructions within that template 
are applied to the source document and the data nodes are copied to the result 
tree. For the purposes of this work, the result tree is then formatted into an XML 
document. 

After the root template match, additional templates are necessary to 
transform each part of the source document into the desired result document. 
This XSLT uses a C2IEDM file as the source file and transforms all usable data 
extracted into a UOB compliant document to be used as initialization information 
for simulations in the FAST Toolbox. The following excerpt generally describes 
the basic structure for a document that is compliant with the C2IEDM. 

C2IEDM structure labels class objects as object-type and 
individually identified instances as object-item. Implicit in the 
distinction between type and item is the assumption that data 
relating to object-types will tend to be static (i.e., the values of 
the attributes are not likely to change very often over time), 
whereas the values of attributes of object-items are likely to be 
more dynamic. For example, if a characteristic is about a type 
(e.g., M1A1 Abrams Tank), it is an attribute of object-type. 
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Thus, calibre of main gun, track width, and load class are 
characteristics of object-type. However, the call sign, actual fuel 
level, munitions holdings, and current operational status of a 
specific tank are characteristics of an object-item (NATO, 2002, 

9). 

The result document generated here does not use this structure nor does 
it use these names for its elements. Instead it follows its own schema which is 
uniquely different. A UOB version 7.7 schema-compliant document for unit data 
is partially shown in Figure 20. Upon review it can be seen that the structure is 
significantly different from the C2IEDM structure description given above. 
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?xml version="1.0" encoding=''UTF-8"?> 

<UOB xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance'' xsi:noNamespaceSohemaLooation=''UOB Schema 
7.7.xsd"> 

<ForceStructurelnformalion> 

<Name/> 

<FileName/> 

<Description/> 

<Purpose/> 

<CreatedBy/> 

<CreationDate>2004-04-15</CreationDate> 

<LastModifiedBy/> 

<LastModifiedDate>2004-04-15</LastModifiedDate> 

</ForceStructurelnformation> 

<Relationships> 

<Relationship type=''Operalional Control^ 

<Assigned> 

<UnitNode UIC="WG2LA07> 

</Assigned> 

</Relationship> 

</Relationships> 

<Units> 

<Unit UIC="WG2LA0'' dataSource="ARMYTOE''> 

<Name>1ST SQDN 3D ARMORED CAVALRY, A CAV TRP, CAV SQDN</Name> 

<TypeCode> </TypeCode> 

<LevelCode> </LevelCode> 

<TotalPersonnel> 

<Authorized>132</Authorized> 

<OnFland>132</OnFland> 

</TotalPersonnel> 

<SRC> 

<Code>1 7487L000</Code> 

<Name>CAV TRP, CAV SQDN</Name> 

</SRC> 

<OpfacRule> 

<Code>AB200</Code> 

<Title>AR CO/CAVTRP CDR (TRACK)</Title> 

</OpfacRule> 

<SymbolCode>S*G*UCRVA-*****</SymbolCode> 

<Resource> 

<Personnel code="92Y30''> 

<Desoription>SUPPLY SGT</Description> 

<Grade>E6</Grade> 

<Required>1</Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19K10''> 

<Desoription>TANK CREWMAN</Description> 

<Grade>E4</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Equipment oode='T13305"> 

<Desoription>TANK COMBAT FULL TRACKED: 120MM GUN Ml A2</Description> 
<Required>9</Required> 

</Equipment> 

<Equipment oode="F60530"> 

<Description>FIGHTING VEHICLE: FULL TRACKED CAVALRY HI SURVIVABILITY 
(CFV)</Desorlptlon> 

<Requlred>13</Requlred> 

</Equlpment> 

</Resource> 

</Unlt> 

</Unlts> 

</UOB> 


Figure 20. Example of a partial unit document extracted from UOB version 7.7. 

The following table depicts for the reader the association between the 
elements of the UOB schema and the locations where the data was found in the 
C2IEDM. The paths to the data locations are shown using the XPath language. 
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A careful review of and frequent consultation with this table while reading the 
remainder of this chapter will greatly assist the reader in understanding the 
development described. This table provides the beginning for a complete round- 
trip mapping of the UOB and the C2IEDM in what is believed to be a lossless 
manner. The following is provided to enhance the understanding of the table 
below. Attributes directly follow the element they are assigned to. Some 
elements have more than one attribute. The word “None” indicates that no 
correspondence was found between the C2IEDM and the UOB for that element 
or attribute. The word “Unknown” indicates that there may be a correspondence 
but that the author was unable to locate it. 


Table 1. Table of correspondences between the elements in the UOB schema and 
the XPath expressions pointing to the location of the data in the C2IEDM. 


Table of Correspondences between UOB and C2IEDM 

Elements and Attributes from 
the Unit Order of Battle (UOB) 
schema 

Attributes in BOLD font 

Command and Control Information Exchange Data Model 
(C2IEDM) 

XPath expressions to data for UOB elements shown in 

Courier New font 

UOB 

None 

ForceStructureInformation 

None 

Units 

None 

Name 

None 

FileName 

None 

Description 

None 

Purpose 

None 

CreatedBy 

None 

CreationDate 

None 

LastModifiedBy 

None 
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Table of Correspondences between UOB and C2IEDM 


LastModifiedDate 

None 

Unit* 

/BattlespaceData/OBJECT-ITEM/ORGANISATION/UNIT 

* depends on whether looking 
at item or type 

/BattlespaceData/OBJECT-TYPE/ORGANISATION- 

TYPE/UNIT-TYPE 

UlC 

Unknown 

dataSource 

None 

Name 

/BattlespaceData/OBJECT- 

ITEM/ORGANIZATION/UNIT/unit-formal-abreviated- 

name 

Present 

/BattlespaceData/LOCATION/POINT/ 

Name 

Unknown 

Latitude 

/BattlespaceData/LOCATION/POINT/ABSOLUTE- 
POINT/absolute-point/absolute-point-latitude- 
coordinate 

Longitude 

/BattlespaceData/LOCATION/POINT/ABSOLUTE- 
POINT/absolute-point/absolute-point-longitude- 
coordinate 

DescriptionCode 

/BattlespaceData/OBJECT-TYPE/ORGANISATION- 

TYPE/GOVERNMENT-ORGANISATION-TYPE/MILITARY- 

ORGANISATION-TYPE/UNIT-TYPE/unit-type-category- 

code 

LevelCode 

/BattlespaceData/OBJECT-TYPE/ORGANISATION- 

TYPE/GOVERNMENT-ORGANISATION-TYPE/MILITARY- 

ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code 

Resource* 

/BattlespaceData/OBJECT-ITEM/HOLDING 

* depends on whether looking 
at item or type 

/BattlespaceData/OBJECT-TYPE/HOLDING 

Personnel* 

/BattlespaceData/OBJECT-ITEM/HOLDING 

* depends on whether looking 
at item or type 

/BattlespaceData/OBJECT-TYPE/HOLDING 

code 

/BattlespaceData/OBJECT-TYPE/object-type-name 

Description 

Unknown 
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Table of Correspondences between UOB and C2IEDM 

Grade 

/BattlespaceData/OBJECT-TYPE/PERSON-TYPE/person- 

type-rank-code 

Required* 

/BattlespaceData/OBJECT-ITEM/HOLDING/holding- 

operational-quantity 

* depends on whether looking 
at item or type 

/BattlespaceData/OBJECT-TYPE/HOLDING/holding- 

operational-quantity 

Authorized* 

/BattlespaceData/OBJECT-ITEM/HOLDING/holding- 

total-quantity 

* depends on whether looking 
at item or type 

/BattlespaceData/OBJECT-TYPE/HOLDING/holding- 

total-quantity 

Equipment 

/BattlespaceData/OBJECT-TYPE/MATERIEL- 

TYPE/EQUIPMENT-TYPE 

code 

/BattlespaceData/OBJECT-TYPE/object-type-name 

Required* 

/BattlespaceData/OBJECT-ITEM/HOLDING/holding- 
operational-quantity 

* depends on whether looking 
at item or type 

/BattlespaceData/OBJECT-TYPE/HOLDING/holding- 

operational-quantity 

Authorized* 

/BattlespaceData/OBJECT-ITEM/HOLDING/holding- 

total-quantity 

* depends on whether looking 
at item or type 

/BattlespaceData/OBJECT-TYPE/HOLDING/holding- 

total-quantity 


2. Force Structure Information 

After reviewing the schema governing the result document, the XSLT 
transformation process begins using a template that simply outputs the 
administrative information for the unit which is called 

Forcestructureinformation in the result document. This section includes 
information about the document like the unit name and when the document was 
created or modified. Figure 21 shows this template and the XSLT rule that calls 
it. Several templates are needed to fully extract all information about the unit in 
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question from the C2IEDM model. Those templates deal with unit data, 
personnel data and equipment data. 


<xsl :call-template name="FileHeader"/> 

<xsl template name=''FileHeader"> 

<xsl:element name=''Name"/> 

<xsl:element name=''FileName"/> 

<xsl:element name=''Description''>Document generated using XSLT on XML C2IEDM Ver 6.1 nnodel</xsl:element> 
<xsl:element name=''Purpose7> 

<xsl:element name=''CreatedBy">C2IEDM From Command and Control System</xsl:element> 

<xsl:element name=''CreationDate"/> 

<xsl:element name=''LastModifiedBy"/> 

<xsl:element name=''LastModifiedDate7> 

</xsl:template> 


Figure 21. XSLT template used to extract ForceStructureInformation from 

C2IEDM. 

Figure 22 shows the results of the XSLT used above. This portion of the 
stylesheet is very easy to understand and requires little processing on the part of 
the XSLT processor because no computations are being conducted. The 
instructions given to the parser are to simply create the elements listed above 
and output them as seen below. 


<ForceStructurelnformation> 

<Name/> 

<FileName/> 

<Description>Document generated using XSLT on XML C2IEDM Ver 6.1 model</Description> 
<Purpose/> 

<CreatedBy>C2IEDM From Command and Control System</CreatedBy> 

<CreationDate/> 

<LastModifiedBy/> 

<LastModifiedDate/> 

</ForceStructurelnformation> 


Figure 22. ForceStructureInformation output of XSLT of C2IEDM. 

3. Unit Identification 


To begin the transformation of unit identification data a handle is required 
for each unit contained in the C2IEDM model. Once the handle is obtained, 
using it to assist in the traversal of the model provides a relative amount of 
certainty that the information extracted belongs to the unit assigned the handle. 
The handles used for traversing the C2IEDM are the object-item-id and 
object-type-id. These are extracted from the C2IEDM when the template 
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shown in Figure 23 is called to obtain the unit’s name. This is done for two 
reasons. First it ensures that the ids are attached to that particular unit and no 
other. Second obtaining the id’s at this level and saving them into variables 
allows them to be passed into other templates. 


<xsl:template match="unit-formal-abbreviated-name"> 

<xsl: element name="Unit"> 

<xsl:attribute name="UIC" /> 

<xsl:attribute name="dataSource" /> 

<xsl:element name="Name"> 

<xsl: value-of select="." /> 

</xsl: element> 

<xsl: variable name="Objectlteml D" select=".. /object-item-id" /> 

<xsl: variable name="ObjectTypel D" select=".. /OBJ ECT-ITEM-TYPE/object-type-id" /> 
<xsl:call-template name="RelativeUnitLocation"> 

<xsl: with-param name="UnitObjectlteml D" select="$Objectlteml D" /> 

<xsl: with-param name="UnitObjectltemLocationI D" select=".. /OBJ ECT-ITEM- 
LOCATION/location-id" /> 

</xsl: call-template> 

<xsl:call-template name="UnitTypeCategoryCode"> 

<xsl: with-param name="OTypel D" select="$ObjectTypel D" /> 

</xsl: call-template> 

<xsl:call-template name="UnitTypeSizeCode"> 

<xsl: with-param name="ObjTypl D" select="$ObjectTypel D" /> 

</xsl: call-template> 

<xsl:element name="Resource"> 

<xsl:call-template name="PersonnelHoldings" /> 

<xsl:call-template name="EquipmentHoldings" /> 

</xsl: element> 

</xsl: element> 

</xsl:template> 


Figure 23. Main template used within the XSLT to extract unit information from 

the C2IEDM. 


In order to extract the unit’s name, the parser is directed to follow the path 
in the apply-templates call. The select attribute of the xsi: vaiue-of element 
extracts the name of the unit and acts as the starting point for the rest of the 
transformation. From there the parser is instructed to back up three levels to 
extract the object-item-id from the object-item element and the 
object-type-id from the object-item-type element. Once this is 
complete the handles for the object-item and object-type are set. Figure 24 
shows an XMLSpy grid view of part of the BIXS containing the object-item, 
OBJECT-TYPE and UNIT elements of the model. 
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REPORTING-DATA a"d to 
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REPORTING-DATAs. 


Figure 24. Grid view of BIXS containing object-item-id, object-item- 

type and UNIT constructs. 

4. Personnel Identification and Extraction 

Figure 23 includes two template calls, one for Personnel holdings and one 
for Equipment holdings. The extraction and formatting of the personnel holdings 
is discussed in this section. The UOB version 7.7 schema dictates that 
personnel, equipment and aircraft are used as resources as can be seen in 
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Figure 25. This thesis is focused on Personnel and Equipment holdings of a 
specific U.S. Army unit that contains no aircraft. Recommended future work 
includes increasing the robustness of this XSLT to include all equipment specific 
to the U.S Navy, Air Force, Marines and Coast Guard. 



r--; Personnel ^ 

0 ..X 


Equipment [+1 

'r. 



-. -N>“ 
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Figure 25. Resource construct found in UOB schema. 

The expanded personnel information included in the target UOB schema 
is shown in Figure 26. Not all of this information is required to initialize a 
simulation or can be found within a command and control system. The items 
focused on here are the Description, Grade, (Quantity) Required and 
(Quantity) Authorized elements. These are items that are extractable from 
the C2IEDM. Recommendations for national modifications to the C2IEDM to 
include more specifics about personnel are being made to the MIP through works 
such as this thesis. 

Resources in the UQB are classified as holdings in the C2IEDM as 
shown in Figure 27. In order to extract information from the C2IEDM pertaining 
to personnel three templates are called. First is the PersonnelFloldings template 
seen in Figure 28, the second is the PersonnelTemplate seen in Figure 29 and 
the third is the PersonnelHoldingNumbers in Figure 30. The PersonnelFloldings 
template instructs the XSLT processor to backup from its current location where 
the formal unit name was obtained, to the holding element of the C2IEDM 
model. There it extracts the holding object-type-id for each holding and 
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places them into a temporary variable called hoidingOb jectTypeiD. This 
variable is then compared to the object-type-ids from each of the object- 
type elements. Two tests are then conducted to ensure that the holdings are for 
the same specified object-item and are coded as personnel objects. Once 
those two tests are passed the XSLT processor outputs the structure for the 
result document and the contents found in the C2IEDM model. The 
xsi: vaiue-of element with select attribute located inside the attribute 
named code selects the MOS name of the object-type from the C2IEDM 
structure. 

The PersonnelTemplate is responsible for extracting the Grade 
information necessary for the result document. When this template is called it 
maintains the scope of the PersonnelHoldings template. This means that the 
scope of the ob ject-item-id and object-type-id are not lost which again 
helps ensure that the information being tested for and extracted is connected to 
the personnel holdings of the unit being examined. Currently, the C2IEDM 
merges officer ranks of 01 ’s and 02’s together in one grade called 0F1. 
Additionally, enlisted ranks above E7 Sergeant First Class and Warrant Officer 2 
do not exist. While this is adequate for many other countries it is not acceptable 
for the US military and additional ranks are necessary. Upon U.S. 
implementation of the C2IEDM as the standard data interchange model, a 
national extension would be required to encompass these additional rank 
requirements. Instructions pertaining to the election of model extensions can be 
found on the MIP website in the documentation section under the Guide to 
Change Proposals (CP) (MIP, 2004a). 
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Figure 26. Expanidecd Personnel element foun(j in UOB schema. 
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object-item-id 
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Figure 27. HOLDING construct found within the C2IEDM. 
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<xsl: template name="PersonnelHoldings"> 

<xsl:for-each select="../../../HOLDI NG"> 

<xsl: variable name="holdingObjectTypelD" select="object-type-id" /> 

<xsl:variable name="holdingObjectltemlD" select="object-item-id" /> 
<xsl:for-each select="../../OBJ ECT-TYPE"> 

<xsl: variable name="objectTypel D" select="object-type-id" /> 

<xsl: if test="$objectTypel D = $holdingObjectTypel D"> 

<xsl: if test="object-type-category-code/* [local-nameO = 'PE']"> 
<xsl:element name="Personnel"> 

<xsl:attribute name="code"> 

<xsl: value-of select="object-type-name" /> 

</xsl: attribute> 

<xsl:call-template name="PersonnelTemplate" /> 

<xsl:call-template name="PersonnelHoldingsTemplate" /> 
</xsl: element> 

</xsl: if> 

</xsl: if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> _ 


Figure 28. PersonnelHoldings template from C2IEDM to UOB XSLT. 


<xsl:template name=''PersonnelTemplate''> 

<xsl:element name="Description"/> 

<xsl:element name="Grade"> 

<xsl:choose> 

<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:when test=''PERSON-TYPE/person-type-rank-code/* 
<xsl:otherwise>Unknown</xsl:otherwise> 

</xsl:choose> 

</xsl:elennent> 

</xsl:template> 


[local-nameO 

[local-nameO 

[local-nameO 

[local-nameO 

[local-nameO 

[local-nameO 

[local-nameO 

[local-nameO 

[local-name{) 

[local-nameO 

[local-nameO 

[local-name{) 

[local-nameO 

[local-nameO 

[local-nameO 

[local-nameO 

[local-name{) 

[local-nameO 


'OF1']''>01/02</xsl:when> 
'OF2']''>03</xsl:when> 
'OF3']''>04</xsl :when> 
'OF4']''>05</xsl :when> 
'OF5']''>06</xsl :when> 
'OF6']''>07</xsl :when> 
'OF7']">08</xsl :when> 
'OF8']''>09</xsl :when> 
'OF9']''>10</xsl:when> 
'OR1 ']”>£ 1 </xsl :when> 
'OR2']''>E2</xsl :when> 
'OR3']''>E3</xsl :when> 
'OR4']''>E4</xsl :when> 
'OR5']''>E5</xsl :when> 
'OR6']''>E6</xsl :when> 
'OR7']''>E7</xsl:when> 
'OR8']''>W 1 </xsl :when> 
'OR9']''>W2</xsl:when> 


Figure 29. PersonnelTemplate template called within the PersonnelFloldings 

template from C2IEDM to UOB XSLT. 


The last template call to the PersonnelFloldingNumbers template, instructs 
the XSLT processor to extract the data held in the hoiding-operationai- 
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quantity and holding-total-quantity eiGmentS for the OBJECT-TYPE 

specified. Figure 30 provides the template used for this operation. An 
assumption is made here that the holding-operational-quantity and the 
holding-total-quantity correspond to the Required and Authorized 
portions of the personnel construct for the UOB seen previously in Figure 26. 
Once the processor is finished with the template the personnel portion of the 
result document is complete. 


<xsl:template name="PersonnelHoldingNumbers"> 

<xsl:element name="Requirecl"> 

<xsl: value-of select="HOLDI NG/holding-operational-quantity" /> 
</xsl: element> 

<xsl:element name="Authorized"> 

<xsl: value-of select="HOLDI NG/holding-total-quantity" /> 

</xsl: element> 

</xsl:template> _ 


Figure 30. PersonnelFloldingNumbers template used to extract the quantities of 
required and authorized personnel from the C2IEDM. 

5. Equipment Identification and Extraction 

The extraction of equipment holdings from the C2IEDM is more difficult 
due to the many different types or categories of equipment that the C2IEDM 
allows. The unit being examined in this work is an Armored Cavalry unit that 
contains all of the types of equipment that are classified by the C2IEDM except 
for vessels and railcars. Figure 31 depicts the equipment structure required in 
the UOB schema. For each piece of equipment in a unit a description of the 
piece of equipment, the required number of pieces for the unit, the authorized 
number of pieces and the number of pieces actually on hand is recorded. While 
this is straightforward enough, the C2IEDM does not group equipment in such a 
compact manner. To begin the traversal of the C2IEDM for equipment, it is 
necessary to again iterate through the unit’s holdings found in the holding 
element of the model. This time, a test is conducted to see if the unit holdings 
are of type materiel-type. Equipment is initially grouped under the 
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OBJECT-TYPE/MATERIEL-TYPE construct in C2IEDM. Further subdivisions 
occur after this point which categorizes equipment as Land-weapon-Type, 
Aircraft-Type, etc. 


r--!” Description ^ 

I Ecu^' t : Air i ^ar-re 
• sssccated ■. r :"•£ 



T'' S i i -i . 

^ Ec\i ZrT^'-z resource cata. 


-1 

Required ! 
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Z’ir'“Q:'~~ its »vart'^e 't: S50”. 

For MIDB Uttar'S s 
'eat ve » r'€ oare": 
re »:a "uroero^r tar.- 
a'Z- o'”e-: assessed M oe 
■.vdr durerzer 'A^. 


Authorized Ij 


For JS J'^ts rvs i ■ i 
ouar’v or er-.- -■-^e"t zo oe 
2 ssc-ec to re 

ts oeacet “e 

-■= 50 ". For MIDB u-'ts 
t" s s reat -.'e zo re oare-t 
e^tt, rexta "u'^nercr 
"■ ta";' eow p“e-: assessed 
to De oeacet -^e auror2ec 

(pa;. 


---• OnHand ; 

For u-ts , 5 5 :-e 
Oja"tr>' of eou o'^e^t o" 
^a"5 •reu"t. For 
MIDBu'-tsrs sreaf.'eto 
ra oa'e*: e-tr,'. re xta 
'Xi'nser of zs~/ 
ecu yrie^t assessed to x 
or-^s^'C (OH'. 


Figure 31. Equipment construct found in DOB schema version 7.7. 


Figure 32 shows the materiel-type structure found in the C2IEDM. 
Figure 33 shows the first of three templates used to extract equipment resources 
from the C2IEDM. The first template sets the conditions for identifying the type 
of holding for the unit as that of materiel-type. This is important because 
holdings in the C2IEDM may be of several different types. Implementation of this 
template begins by instructing the XSLT parser to again back up to the holding 
element in the C2IEDM maintaining scope and extracting the object-type-id 
associated with the holding. Then the parser moves to the object-type 
element and compares the object-type-id found there with the one found in 
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the HOLDING element. If the two match the parser then checks to see if the 
category code found within that object-type is of type ma which indicates 
MATERIEL-TYPE. When that test executes successfully the template found in 
Figure 34 is called and executed. 
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materiel-type-id 
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oO;ect-Cv'Pe-«i ^ a 
soec/c MATERia-TYPE (a 
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Figure 32. materiel-type construct found in the C2IEDM. 
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<xsl:template name="EquipmentHoldings"> 

<xsl:for-each select="../../../HOLDING"> 

<xsl:variable name="holdingObjectTypelD" select="object-type-id"/> 
<xsl:for-each select="../../OBJECT-TYPE"> 

<xsl:variable name="objectTypelD" select="object-type-id"/> 

<xsl:if test="$objectTypelD = $holdingObjectTypelD"> 

<xsl:if test="object-type-category-code /* [local-name() = 'MA']"> 
<xsl:apply-templates select="MATERIEL-TYPE"/> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> 


Figure 33. EquipmentHoldings template used to determine object-type in 
the equipment extraction portion of the C2IEDM to DOB XSLT. 


<xsl:template match="MATERIEL-TYPE"> 

<xsl:if test="materiel-type-category-code /* [local-name() = 'EQ']"> 

<xsl:element name="Equipment"> 

<xsl:attribute name="code"> <xsl:value-of select="../object-type-name”/> <xsl:attribute/> 
<xsl:apply-templates select ="./EQUIPMENT-TYPE"/> 

<xsl:element name="Required"> 

<xsl:value-of select="../HOLDING/holding-operational-quantity"/> 

</xsl:element> 

<xsl:element name="Authorized"> 

<xsl:value-of select="../HOLDING/holding-total-quantity"/> 

</xsl:element> 

</xsl:element> 

</xsl:if> 

</xsl:template> 


Figure 34. materiel-type template used to test the classification of 
equipment in the C2IEDM to UOB XSLT. 
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The template in Figure 34 begins by conducting a test to see if the type of 
materiel identified in the model is of equipment type. It does this by checking to 
see if the materiei-type-category-code is EQ. Then it begins to output 
part of the result structure necessary for the output document. It then calls the 
template that will identify and extract the type of unit equipment it has found. 
Figure 35 shows the equipment-type construct located in the C2IEDM and 
Figure 36 shows a portion of the XSLT template created to determine the 
equipment’s equipment type. This template uses a choose construct with a 
series of when tests to determine the type of equipment it has identified. The 
result of this template is that the type of equipment is identified and the parser 
extracts the description of the piece of equipment from its category code. The 
parser then returns to the template seen in Figure 34 and extracts the quantities 
on hand and authorized for the item of equipment. 
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Figure 35. equipment-type construct found in C2IEDM. 
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<xsl: template match="EQUI PMENT-TYPE"> 

<xsl: element name="Description"> 

<xsl: choose> 

<xsl:when test="equipment-type-category-cocle/* [local-nameO = 'AIRCFT']"> 

<xsl: value-of select="AI RCRAFT-TYPE/aircraft-type-subcategory-code/*/@value" /> 
</xsl: when> 

<xsl:when test="equipment-type-category-code/* [local-nameO = 'ELCTRN']"> 

<xsl: value-of select="ELECTRONIC-EQUI PMENT-TYPE/electronic-equipment-type- 
subcategory-code/*/@value" /> 

</xsl: when> 

<xsl:when test="equipment-type-category-code/* [local-nameO = 'ENGEQ']"> 

<xsl: value-of select="ENGI NEERI NG-EQUI PMENT-TYPE/engineering-equipment-type- 
category-code/*/(a)value" /> 

</xsl: when> 

<xsl:when test="equipment-type-category-code/* [local-nameO = 'LNDWEP']"> 

<xsl: value-of select="LAN D-WEAPON-TYPE/land-weapon-type-category- 
code/*/@value"/> 

</xsl: when> 

<xsl:when test="equipment-type-category-code/* [local-nameO = 'MISCEQ']"> 

<xsl: value-of select="MISCELLANEOUS-EQUI PMENT-TYPE/miscellaneous-equipment- 
type-category-code/*/(5)value" /> 

</xsl: when> 

<xsl:when test="equipment-type-category-code/* [local-nameO = 'NBCEQ']"> 

<xsl: value-of select="NBC-EQUI PMENT-TYPE/nbc-equipment-type-category- 
code/*/@value"/> 

</xsl: when> 

<xsl: otherwise /> 

</xsl: choose> 

</xsl: element> 

</xsl:template> 


Figure 36. Partial EquipmentType template used to extract equipment 
descriptions from the equipment-type construct found in C2IEDM. 


Figures 37 and 38 show the equipment-type-category-code and 
land-weapon-type-category-code constructs from the C2IEDM. Once the 
parser has gotten down to the command xsi: vaiue-of seen in Figure 36, it 
extracts the content of the attribute value which contains a brief description of 
the piece of equipment. This data is necessary input for the description 
element found in the UOB schema compliant result document. 
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Figure 37. Equipment-type-category-code construct found in the 

C2IEDM. 
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Figure 38. Land-weapon-type-category-code construct found in the 

C2IEDM. 
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6 . 


Unit Present Location 


To obtain the unit’s present location from the C2IEDM more than the 
object-item-id and object-type-id are required. The structure within 
the C2IEDM that contains the longitude and latitude for the unit object is not 
concerned with the object-item or object-type-id. It is concerned with a 
location-id. Figure 39 shows the template that is executed to extract the 
present location for the unit. 


<xsl:template name=''RelativeUnitLocation"> 

<xsl:param name="UnitObjectltemlD7> 

<xsl:param name="UnitObjectltemLocationlD7> 

<xsl:element name="Present"> 

<xsl:element name=''Name''>This is the Name of the Current Geographical Location of this unit</xsl:element> 
<xsl:for-each select="../../../OBJECT-ITEM-LOCATION"> 

<xsl:variable name=''ObjectltemLocationObjectltemlD'' select="object-item-id"/> 

<xsl:variable name=''ObjectltemLocationLocationlD" select=''location-id"/> 

<xsl:for-each select="../../LOCATION''> 

<xsl:variable name="LocationlD'' select=''location-id7> 

<xsl:if test=''$UnitObjectltemlD = $ObjectltemLocationObjectltemlD"> 

<xsl:if test=''$UnitObjectltemLocationlD = $LocationlD''> 

<xsl:element name="Latitude"> 

<xsl:value-of select="POINT/ABSOLUTE-POINT/absolute-point-latitude-coordinate7> 
</xsl:element> 

<xsl:element name="Longitude"> 

<xsl:value-of select="POINT/ABSOLUTE-POINT/absolute-point-longitude-coordinate7> 
</xsl:element> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 


Figure 39. Relative Unit Location template to extract latitude and longitude for 

the unit current location. 


When the template is called two parameters are passed to it. The first is 

the UnitObjectitemiD which contains the original object-item-id 

extracted for the unit in the first template call. The second parameter, 
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unitob jectitemLocationiD is the location-id Obtained from the 
OBJECT-ITEM-LOCATION element of the BIXS. This parameter is carefully 
selected by backing out from the context of the unit-formal-abbreviated- 
name to the OBJECT-ITEM-LOCATION Structure and then down the tree to the 
location-id. The first iteration inside the template searches through all of the 
object-item-ids and location-ids found within the OBJECT-item- 
LOCATiON Structure in the model and assigns them to local variables. A second 
iteration is then used to search through all of the location-ids in the model 
found in the location structure and places them in a local variable as well. 

From there the object-item-ids and location-ids are checked against 
the ones passed into the template. The first test conducted in the template 
checks to see if the object-item-id that was passed to the template matches 
the one extracted from the object-item-location structure. 

The second test conducted in the template checks to see if the 
location-id extracted from the location element of the model matches the 
one extracted from the object-item-location element. This test ensures 
that the location-ids match and allows the extraction of the latitude and 
longitude from the model to commence. The values of latitude and longitude are 
located within the point structure of the BIXS. Before the extraction of the 
latitude and longitude, the parser’s context is in the location structure. The 
POINT element is a child of location so all that is required to extract the 
latitude and longitude is to direct the parser to the location of the values using the 
XPath expression seen within the template. 

7. Unit Type Category Code 

One piece of information that is important to have is the military unit’s 
type. The focus here is on a U.S. Army Cavalry Troop whose primary mission is 
reconnaissance and combat operations. Units in the U.S Army are grouped into 
one of three class types, combat, combat service support and combat support. 
Armored Cavalry troops, like A Troop 1/3 ACR are categorized as combat units. 

Examples of combat service support and combat support unit types are 
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Transportation and Military Intelligence units respectively. Figure 40 shows the 
UnitTypeCategoryCode template from the XSLT stylesheet used to extract what 
the UOB denotes as the DescriptionCode for the unit. Only three codes are 
necessary for the classification of the unit type here: AAC for combat, AAS for 
combat support and AAV for combat service support. Additional codes are 
available within the UOB which satisfy the other services and countries’ 
requirements to classify their units. 

<xsl:template name =”UnitTypeCategoryCode”> 

<xsl:param name="OTypelD7> 

<xsl:element name="DescriptionCode"> 

<xsl:for-each select=''. /OBJECT-TYPE"> 

<xsl:variable name="LocalObjectTypelD" select="object-type-id"/> 

<xsl:if test="$OTypelD = $LocalObjectTypelD''> 

<xsl:if test="object-type-category-code/* [local-name() = ’OR']"> 

<xsl:if test="ORGANISATION-TYPE/organisation-type-category-code/* [local-name{) = ’GVTORG’]"> 
<xsl:iftest="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/government- 
organisation-type-category-code/* [local-name{) = 'MILORG’]"> 

<xsl:if test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/MILITARY- 
ORGANISATION-TYPE/military-organisation-type-category-code/* [local-nameQ = 'UNIT']"> 

<xsl:choose> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category-code/*[local-name() = 
'COMBAT']">AAC</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category-code/*[local-name() = 
'COMSER’]">AAV</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category-code/*[local-name() = 
'COMSPT']">AAS</xsl:when> 

<xsl:otherwise>U</xsl:otherwise> 

</xsl:choose> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 


Figure 40. UnitTypeCategoryCode template used to extract data from the 

unit-type-category-code of the BIXS. 
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For this implementation to succeed, one of many tree structures within the 
C2IEDM must be traversed in order. The method to do this within the XSLT is 
through a series of if tests. The tests conducted at each level of the tree check 
node contents and codes to ensure that they meet the specified requirements. 
Step one in the process is to direct the parser to again iterate through all of the 
OBJECT-TYPES in the model and select their object-type-ids. This is done 
so that the extracted object-type-id may be compared against the object- 
type-id passed in during the template call. Matching these ids indicates that 
we are dealing with the correct unit. 

Next the object-type-category-code for the OBJECT-TYPE selected 
is checked to see if it is of type organization-type. This test is required 
because object-types may have several different values within the model and 
only the 'OR' value is needed here indicating that the object is an organization. 
Next the parser checks to see if the organisation-type-category-code of 
that ORGANISATION-TYPE is GVTORG. The GVTORG code indicates a 
GOVERNMENT-ORGANISATION-TYPE and is the One we are concerned with. 
Figure 41 shows the organisation-type structure of the C2IEDM. Figure 42 
depicts the organisation-type-category-code. 
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Figure 41. organisation-type structure found in the BIXS. 
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Figure 42. The expanded organization-type-category-code found 
within the organisation-type structure from the BIXS. 


Next the parser proceeds one level deeper into the source tree structure 
to determine if the government-organisation-type ' s government- 
organisation-type-category-code is MiLORG. MiLORG is the Category 
code indicating an organization is a military organization. Figure 43 depicts part 
of the tree structure containing the government-organisation-type- 
category-code Structure found within the BIXS schema that is traversed to 
obtain this information. Now the parser checks the structure seen in Figure 44 to 
see if the military-organisation-type has a miiitary- 
organization-type-category-code of UNIT. This indicates that the node 
being examined is a unit and that the only further processing required is to 
extract the information referencing what type of unit we are examining. The 
extraction of the code labeling the unit is completed using a choice statement 
that is similar to a switch statement in other coding languages. The choice 
statement may be reviewed in Figure 40. Figure 45 shows the partial tree 

structure leading to the unit-type node of the BIXS schema. 
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C2IEDM. 
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MiLiTARY-ORGAiNiSATiON-TYPE Structure within the C2IEDM. 


Figure 46 shows the expanded unit-type structure found within the 
C2IEDM. This construct in the source document is the final focal point for both 
template extractions of the DescriptionCode being attempted here and the 
Leveicode discussed in the next section. These two pieces of information are 
the last two pieces extracted to build our UOB compliant unit source document. 
Figure 47 shows the expanded view of the unit-type-category-code with 
the three unit types found within the unit-type node. A great deal of 
information is contained within the unit-type structure that is not examined 
within the current work. Extensions of this research include increasing the 
robustness of the unit document to include other service requirements, some of 
which may be satisfied through data extraction from the unit-type element. 
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Figure 46. unit-type structure found in the BIXS containing both the unit- 
type-category-code and the unit-type-size-code. 


81 

















































8. Unit Type Size Code 

The last piece of the unit document deals with the echelon of the unit. The 
term echelon is synonymous in this instance with size. Army units range in size 
from sections to armies. The size of the unit in this work is a Troop. Troops in 
the U.S. Army are special organizations found only in Cavalry units. Outside of 
Cavalry units, this size of unit is called a Company. Companies and Troops 
contain the same level of commander although their organizations differ greatly. 
Generally, the standard size term used when discussing a unit of this level or 
echelon, is Company. This is noticeable within the C2IEDM as there is not a 
Troop echelon within the model. UOB on the other hand does include Troop as 
one of its standard unit echelons. The two closest matches to be found within 
C2IEDM are company and company-team. For some, the company-team may 
be a more accurate description of a Cavalry Troop. This is due to the makeup of 
a Troop. A Cavalry Troop within a heavy Cavalry Regiment will have a mix of 
vehicles including tanks, armored personnel carriers (ARC), cavalry fighting 

vehicles (CFV), armored maintenance recovery assets and wheeled vehicles 
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ranging in size and hauling capability from y 2 to 5 tons. While a company-team 
does not have the expanse of assets that a Troop has, it does contain a mix of 
tanks, infantry fighting vehicles (IFV), APCs, wheeled vehicles and may have 
attached to it additional assets that it would not normally have. This is generally 
done if the unit is being assigned a mission that it was not originally designed for 
like a screening mission. Screen, Guard and Cover missions are standard for 
the Cavalry but not necessarily for Armored or Mechanized Brigades. Figure 48 
shows the partial template that extracts the unit-type-size-code from the 
C2IEDM. The full template may be viewed in Appendix D. 

<xsl:template name="UnitTypeSizeCode"> 

<xsl:param name=''ObjTyplD7> 

<xsl:element name="LevelCode"> 

<xsl:for-each select=''../. ./../../OBJECT-TYPE’'> 

<xsl:variable name-'LocalObjTypID'' select=''object-type-id7> 

<xsl:if test=''$ObjTyplD = $LocalObjTyplD"> 

<xsl:if test="object-type-category-code/* [local-name{) = 'OR']"> 

<xsl:if test-'ORGANISATION-TYPE/organisation-type-category-code/* [local-name{) = 'GVTORG']"> 
<xsl:if test=''ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/government- 
organisation-type-category-code/* [local-name() = 'MILORG']"> 

<xsl:iftest="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/MILITARY- 
ORGANISATION-TYPE/military-organisation-type-category-code/* [local-name() = 'UNIT']''> 

<xsl:choose> 

<xsl:when test=''ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* [local-nameQ = 'BDE’]''>BDE</xsl:when> 
<xsl:when test=''ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* [local-name() = 'CBTTM']">CO</xsl:when> 
<xsl:when test=''ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* [local-nameQ = 'COY']">CO</xsl:when> 

<xsl :otherwise>U</xsl :otherwise> 

</xsl:choose> 

</xsl:if> 

</xsl:lf> 

</xsl:lf> 

</xsl:lf> 

</xsl:if> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 


Figure 48. Partial template used to extract the unit Leveicode necessary for 

the UOB result document. 
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It so happens that this template is identical to the one used to extract the 
unit DescriptionCode information in the previous section. The only difference 
in this template is in the choose construct. For this implementation the 
necessary information is located in the unit-type-size-code. Figure 49 
shows the partial tree structure encompassing the unit-type-size-code 
structure. Once the proper match is made inside the choose statement the 
information is extracted and the result document is complete. 


- n, MILITARY-ORGAtJISATIOII-TYPE 
A 

GOVERNMENTORGANISATION-TYPE 
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Figure 49. Partial unit-type-size-code structure found within the C2IEDM 
used to obtain the unit Leveicode for the UOB compliant result document. 

D. SUMMARY 

This chapter has discussed the importance of XML and has provided an 

exemplar using XML and XSLT to transform data about a military unit from a 

form understood by a command and control system into a form usable by a 

simulation. The exemplar shows the enabling power of XML and XSLT as 

methods of data representation that facilitate interoperability. The work 

completed here provides a reason why a solid understanding of XSLT by 

84 


u UlllT-TYPE l3- 




0..X 

A 

MIUTARYORGANISATIO 
N-TYPE .-/hose strucojre -s 
O'^scroec oy co'rsece'*: 
authonr,'. 


unit-type-size-code 

T*® wec-^c vate ra: 
represe^ 'eiat ve sae of 
r^cor'nc— - cccectec 
ccY^^-rato^ cr ta-. 
^or“2tcrs. 


] COY I 

Base admtf'.scrarve a'V 
tactea .‘'r ' "z,~. a-^ a'e 
servees of r.c A. , - 
CO^M"V son a COm'*'5"C 
eve oeew a oar:a on a*^ 
atjove a paoxr. 


Ar ooeratona 

s oasec c* a" 

Z COJnn.3**;' 3nd Anck 
as een-eocs of o&«f 
sopooT'^ a-^s and servees 
a ocatec accord ng to neec. 


] CORPS I 

A fbrmaccn erger T'a" a 
d viscn Put yr-i er tTa' a' 
ar^V V i'“ ■' g'Oup. It 

uica"i' conssa tc t*so or 
"^fs c vsons xgerer .. “ 
suPOorp"g a'-s a-d 
servees. 


DIV 


A actea u’'*t'V^ato^ rat 
s a Tajer acn-r^sa-at ve anc 
tactea un^Sorr-atc" rat 
r-r -es - tse^re 

... -ri wvoes 

susta 

'3''ger ra- a 

-2g-leritVgace a"C s~a er 
:-5- a cc 


Ar organsaton of snos. 
arcra^ Va-.'>e ^rces. and 
sfore-pasec 

























simulation developers and its incorporation into the process of data interchange 
is vital to the extensibility of models and simulations. This is a key point. 

Since XML is extensible and platform independent its use has fostered 
interoperability without the post development requirement for special wrapper or 
interface. While it is arguable that if all simulations and C2 systems were written 
in the same computer language this would also be possible, it is not true that the 
extensibility and ease of use would be comparable. The focus here is on the 
data and its representation not the code used to run either application. The 
C2IEDM representation used in this example was vital to the success of the 
transformation due to its representation using XML. Without this representation 
of the C2IEDM a more complex procedure would have been necessary for the 
extraction of the data contained within a database. The bottom line is “the role of 
XML Transformation for interoperability cannot be understated, since it allows 
integration of existing databases and systems, and promotes application 
independent information management at the data level” (Neushul, 2003). 

On the other hand, human judgment was applied throughout in order to 
make the data associations summarized in Table 1. The full power of automated 
interoperability across systems will only be realized when software is able to 
understand the common concepts used by different data models and XML 
representations. This is the hope of emerging Semantic Web research and 
applications (Blais, 2004a). 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

New uses are being created on a daily basis for our legacy models and 
simulations in the fight on terrorism. New systems are needed. We no longer 
have a well defined threat. Some say that today’s threat is pan-national and 
asymmetric. Few disagree. 

The importance of knowledgability incorporating XML in the analysis, 
design and development phases of current and future systems cannot be 
overstated. The current lack of interoperability between our command and 
control systems, models and simulations is unacceptable. Precious resources, 
(both money and manpower) are being spent to develop useful tools for both 
military analysts and training professionals, but very little money or time is being 
spent developing the interfaces or interoperability between these systems until 
too late in the development process. It is no longer enough to have great 
software tools. They must also interface with one another and be modular 
enough to support common data models and exchange documents. 

The C2IEDM model incorporates the ontology of the military community, is 
extensible, and has been shown to be interoperable and transformable for use 
with a simulation package. Joint Forces Command (JFCOM) is incorporating the 
C2IEDM in their new command and control structure. The simulation community 
of interest (COI) has recognized that they need to begin focusing on 
interoperability between themselves and the Command and Control COI. Figure 
50 (Chaum and others, 2004) depicts DMSO’s vision for future interoperability 
incorporating many of the concepts addressed in this thesis. The use of XML 
based technologies and architectures such as XMSF enhance the possibilities for 
interoperability, interchange and visualization. 
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Figure 50. DMSO’s vision of future interoperability using C2IEDM (From 

Chaum antj others, 2004) 


This research has provided the reader with several examples of how the 
DoD and academia are working towards interoperable solutions that fit within 
today’s military concept of operations. To say that this work has uncovered the 
“Holy Grail” to fix all of the interoperability difficulties within the DoD would be a 
bit naive. This examination of using the C2IEDM as the data interchange 
method to interface with the FAST Toolbox is only the tip of the iceberg in terms 
of C2/simulation interoperability. The FAST Toolbox is a relatively new set of 
tools that have been built under the purview of interoperability. Other modeling 
and simulation tools such as Vector in Commander (VIC) and Janus are not so 
new and were designed and built during a period when interoperability with C2 
systems was not an issue. Now we are looking for ways to re-engineer these 
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tools to enhance them for today’s warfighting missions and leverage their power 
within other applications. 

The C2IEDM is a complex and powerful data exchange model. Its ability 
to bend to the needs of the user is critical in today’s unpredictable environment. 

It has been tested on several occasions to show that through its use 
interoperability amongst national C2 systems can be achieved and that a 
common operating picture can be shared. This work has shown that using the 
C2IEDM within the Simulation COI, interoperability between a simulation 
package and C2 system using the C2IEDM as the data interchange mechanism 
may also be achieved. This is a critical point. While further enhancements and 
development are necessary for the C2IEDM to completely satisfy the needs of 
many simulation and C2 applications, it can be used now for data interchange 
within some applications. Coupling XML with XSLT provides a sound method for 
describing and transforming data between applications as an after thought but 
careful design including the use of these technologies wrapped in an architecture 
like XMSF will provide extensible, open and interchangeable solution to an old 
and continuing problem within the C2 and simulation COIs. 

Unfortunately there is never enough time to accomplish everything. The 
following lists several projects that can extend the work done in this research to 
make it more robust. 

B. RECOMMENDATIONS FOR FUTURE WORK 

Several items are listed in this section as future work. The first 
recommendation is to complete the work started here by fleshing out this XSLT 
so that any military unit described in the C2IEDM can be extracted and used 
within the FAST Toolbox. The focus here was on a single U.S. Army ground 
Cavalry unit and its main equipment. There were no aircraft, watercraft or 
railroad equipment associated with the unit selected so the XSLT is not designed 
to handle units that have those types of equipment. This is the next logical step 
in extending and completing the current research. 
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In order to accomplish this however, a complete source file(instance 
document) is necessary. One of the difficulties encountered during this work was 
the lack of a complete source file based on the BIXS. In order to test the current 
XSLT process, a source file was auto generated from the BIXS by XMLSpy. 
Values were changed in that source file where the author believed they 
belonged. This resulted in a partial file that has been subsequently built upon 
throughout the development of the XSLT. In order to properly test and evaluate 
this XSLT file, software should be written to extract the data values from the IDA 
C2IEDM database and create a source file based on the BIXS. With this, full and 
rigorous testing of the work created here may be completed. 

The next proposal is the revision of the BIXS created by Capt. James 
Neushul (Neushul, 2003). Neushul’s BIXS is a very complex and lengthy 
document. It is an XML document with a very large hierarchical structure. The 
C2IEDM itself causes this problem with its many to many relationships. When 
exposed using XML, data that is normally contained within a database in tables is 
now replicated many times in many different places within the structure of the 
model. Aside from this, the BIXS is a powerful piece of work. Because the BIXS 
version of the C2IEDM’s data is completely exposed, XSLT may be brought to 
bear on it and there is no reason, other than time, that it cannot be fully 
manipulated to suit the needs of users. A similar rendition of the model using a 
database to hold data values would require additional software to traverse and 
manipulate tables in the databases, something humans alone cannot do. An 
effort to increase the usefulness of the BIXS has been to apply Java Architecture 
for Data Binding (JAXB) to it. This effort has had limited success. This is mainly 
due to the enormous size of the document. One recommended step to revising 
the BIXS is to name the complex types that are found within the model. This will 
help to reduce the size of many of the methods generated by applying JAXB. 

One logical follow-on project of this work is the creation of additional XSLT 

to transform unit data from the UOB version 7.7 schema structure to the BIXS 

(C2IEDM) structure. This may be the next exemplar showing the extensibility of 

the C2IEDM and its value in the C2/simulation communication process. Table 1 
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of this work provides the beginnings for a round trip showing information transfer 
from C2IEDM to UOB and back. Along with this, the implementation of both 
XSLTs in the FAST Toolbox would be the final exemplar to prove that the 
C2IEDM is the logical choice for connecting simulations and C2 systems. 

Another avenue for research is the incorporation of the BIXS into work 
involving tactical chat and tactical messaging. Research and development is 
ongoing involving the use of C2IEDM in the area of mission planning and 
visualization. 

Further research is needed into the MDA concept summarized here. 

Many questions raised during the research into this architecture need to be 
answered before the MDA can be fully understood and utilized outside of the 
OMG. Time will tell if MDA will falter or flourish as a proven architecture for 
software development. 

A chapter of this work that was not realized was the prospect of 
developing a web service to fully expose the UOB toolset. From a user’s 
perspective, the UOB is one stop shopping for data related to military units. As it 
stands, using UOB requires special permissions and a server and client. A more 
robust UOB toolset could use the power of the web to make unit data available 
for any level commander who could use the data along with other applications 
such as X3D, to create realistic training scenarios at the small unit level. These 
types of applications would provide a powerful training environment for units with 
small footprints and smaller budgets. 

Lastly, a full comparison of the two versions of C2IEDM mentioned and 
used here is necessary. Many developers and users alike are unclear as to 
which representation of the C2IEDM will work best for them. While the several 
representations developed may subscribe to the intent of the C2IEDM model 
their presentation methods are in some cases much different. The BIXS and the 
IDA C2IEDM schemas provide two good examples to compare and contrast to 
address what aspects of each are good and bad. One is database centric while 
the other is very much document centric. These constructive reviews should be 
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made available to the developers of the respective versions of the model 
schemas so that they may mature their versions making them stronger and more 
understandable to the many communities of interest that will be implementing 
them in the near future. 

This work began with a focus on improving the data interchange abilities 
of current command and control systems and simulations so that critical training 
might be accomplished during this time of war. Originally the training envisioned 
was the type necessary to prepare soldiers to operate in the stability and support 
operations that we find ourselves in today. Messages from soldiers involved in 
OIF and OEF underscored the need for tools to train and operate in that difficult 
environment. Six months later, many of the challenges remain the same and 
new ones have surfaced especially the need to maintain a training environment 
during ongoing operations. Correspondence monitored since the beginning of 
this work indicates that steps towards the interoperability of C2 systems and 
simulations have taken over the driver’s seat and solutions are starting to appear. 
These solutions are only temporary fixes while the enduring problem remains. 

The technologies focused on in this research were the Extensible Markup 
Language (XML), the Extensible Stylesheet Language for Transformation (XSLT) 
and the Flexible Asymmetric Simulation Technologies (FAST) Toolbox, the 
Command and Control Information Exchange Data Model (C2IEDM) and the 
Model Driven Architecture (MDA). Early in the work it was determined that while 
the MDA provided a promising architecture for certain software development it 
was not suitable for the work to be undertaken here. The C2IEDM was 
examined and utilized with great success and is the leading data model to be 
used within the DoD. The deliverable was an exemplar to show that by using 
XML, XSLT and C2IEDM data could be represented, transformed and 
interchanged between C2 systems and simulation technologies. This was done 
successfully and it has been shown that both XML and XSLT are powerful and 
relatively easy to use and that they provide solid solutions to part of the problem 
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of interoperability, data representation and transformation. C2IEDM is the lynch 
pin that is going to connect C4ISR systems and simulations correctly and 
completely in the future. 
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APPENDIX A. UOB SCHEMA VERSION 7.7 


The following document is the schema used to validate information 
entering and exiting the UOB DAT. It was provided by the DMSO personnel 
responsible for maintaining the UOB toolset. Further information about the UOB 
toolset can be found at http://www.msiac.dmso.mil/UOB . 

<?xml version="1.0" encoding="UTF-8"?> 

<!- edited with XMLSPY v2004 rel. 3 U (http://www.xmispy.com) by JZanakos (Dynamics 
Research Corp) -> 

<!- edited with XML Spy v4.4 U (http://www.xmlspy.com) by Joseph E. Eck (Computing 
Technoiogies, Inc.) --> 

<!-Changed Unit Name to optionai from required. Changed Reiatinship from required to 
optionai. Changed DataSource from required to optionai --> 

<!- Added the optionai field ParentOrg --> 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> 
<xs:element name="UOB"> 

<xs:annotation> 

<xs:documentation>This element contains all UOB data.</xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref="ForceStructurelnformation" minOccurs="07> 

<xs:element ref="Relationships" minOccurs="07> 

<xs:element ref="Units7> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Unit"> 

<xs:annotation> 

<xs:documentation>DataSource also applies to Equipment, Aircraft and Personnel 
Resources, but is not defined for each.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Name" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For US units this is the name of the unit. For MIDB 
units: Translated unit name or identification given the unit by appropriate authority or orders as 
used in official orders or communications within the national military or civilian establishment of 
the country of allegiance. A unit name must be established for every unit in the data base. For 
each Unit logical record, unit naming conventions established in production programs should be 
employed. If official sources are not available, the unit name believed most correct is used, a 
unit's primary designation usually includes service specialty and command 
echelon. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="60"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 
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<xs:element name="Present" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This is a continer element for Present location 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Name" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For US units this is the present Name of the 
geographic location where the Unit is presently located. For MIDB units this is the location 
name for the present coordinates. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="24"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Latitude" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Present Unit latitude of the geographic 

location. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="7"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Longitude" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Present Unit longitude of the geographic 

location. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="8"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Flome" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This is a container element for Flome location 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Name" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For US units this is the name of the 
geographic location where the Unit is garrisoned. For MIDB units this is the location name of 
the coordinates. </xs:documentation> 
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</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="24"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Latitude" minOccurs=''0"> 

<xs:annotation> 

<xs:documentation>The latitude of the geographic location where 
the Unit is garrisoned. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="7"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Longitude" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The longitude of the geographic location 
where the Unit is garrisoned. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="8"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="TypeCode" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A five-character alphanumeric code that uniquely 
identifies each type unit of the U.S. Armed Forces. The first position of Unit Type Code (UTC) 
applies to all the US Services. The UTC is a 5-character A/N code that is associated with and 
allows each type organization to be categorized into a class having common characteristics. The 
first character of the UTC, as described below, identifies the functional category of the unit. Each 
Service may define the function differently or may not have a valid use for the code. Therefore, 
each Service functional definition is provided for the first position of the UTC as appropriate. The 
remaining four characters are Service assigned codes. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="5"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="DescriptionCode" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For US Units this is a 3 Character Unit Description Code 
(UDC) associated with the unit showing unit status (Combat, Combat Support, Combat Service 
Support, Active Duty, National Guard, or Reserve). </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 
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<xs:restriction base="xs:string"> 

<xs:maxLength value="3"/> 

</xs:restnction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="LevelCode" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A three-letter alphanumeric code used to specify the 
organizational level (echelon) of the Unit.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="3"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="TotalPersonnel" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This is a container element for unit personnel 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Authorized" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of authorized 
personnel of the unit. For MIDB units this is relative to the parent entity, the total number of 
military personnel assessed to be war authorized (WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="OnHand" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of personnel 
present for duty in the unit. For MIDB units this is relative to the parent entity, the total number 
of military personnel assessed to be on-hand (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="CountryCode" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>State/Country code associated with the geographic 
location of the Unit.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="2"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Ship" minOccurs=''0"> 

<xs:annotation> 

<xs:documentation>This is a container element for Ship 
data.</xs:documentation> 

</xs:annotation> 
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<xs:complexType> 

<xs:sequence> 

<xs:element name="Category" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For the US Navy this is the Navy category 
type of ship.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="6"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="CategoryName" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The Navy category name of 

ship.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="56"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="HullNumber" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A unique ship type and number located on the 
Hull of a ship. It is composed of the type of ship ie SSBN and a number ie 726 or the CV 
63.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="4"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Class" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A Navy class of ships which other like ships 
are associated ie the Ohio Class. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="25"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="SRC" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This is a container element for SRC 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 


103 


<xs:sequence> 

<xs:element name="Code" minOccurs="0"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="9"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Name" minOccurs="0"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="32"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="OpfacRule" minOccurs="0"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Code" minOccurs="0"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="5"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Title" minOccurs="0"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="46"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="SymbolCode" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Mil-Std 2525-B Symbolic Codes</xs:documentation> 
</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs :string"> 

<xs:maxLength value="157> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Rolledup" minOccurs="0"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="1"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Subtracted" minOccurs="0"> 
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<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="1"/> 

</xs:restnction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="ParentOrg" type="xs:string" minOccurs="07> 

<xs:element name="ORG_EID_S" type="xs:double" minOccurs="0"/> 

<xs:element ref="Resource" minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 

<xs:attributeGroup ref="UnitldentificationCode"/> 

<xs:attribute name="dataSource" use="optional"> 

<xs:annotation> 

<xs:documentation>The source of the unit data ie Conventional Forces Data 
Base (CFDB), Defense Intelligence Agency's (DIA), Moderized Intergrated Data Base (MIDB), 
Conventional Forces Europe (CFE), Generic, or the National Ground Intelligence Center's (NGIC) 
Force!racking Information System (FORTRIS) and others. </xs;documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="10"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element name="Units"> 

<xs:annotation> 

<xs:documentation>This is a grouping element for Units. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref="Unit" minOccurs="0" maxOccurs="unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Relationships"> 

<xs:annotation> 

<xs:documentation>This is a grouping element for Relationships. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Relationship" maxOccurs="unbounded"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Description" type="xs:string" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>A description of the 
relationship. </xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="Assigned" minOccurs="0"> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref="UnitNode" maxOccurs="unbounded"/> 
</xs:sequence> 
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<xs:attribute name="type" type="xs:string" use="optional"/> 
</xs:complexType> 

</xs:element> 

<xs:element name="Unassigned" minOccurs="0"> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref="UnitNode" minOccurs="0" 

maxOccurs="unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

<xs:attribute name="type" type="xs:string" use="required"/> 
</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:attributeGroup name="UnitldentificationCode"> 

<xs:attribute name="UIC" use="optional"> 

<xs:simpleType> 

<xs jestriction base="xs :stri ng"> 

<xs:maxLength value="157> 

</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:attributeGroup> 

<xs:element name="UnitNode"> 

<xs:annotation> 

<xs:documentation>Represents the position of a Unit in a relationship hierarchy. The 
root UnitNode is implicitly defined and multiple roots are allowed. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref="UnitNode" minOccurs="0" maxOccurs="unbounded7> 
</xs:sequence> 

<xs:attribute name="UIC" type="xs:string" use="optional7> 

</xs:complexType> 

</xs:element> 

<xs:element name="ForceStructurelnformation" nillable="true"> 

<xs:annotation> 

<xs:documentation>lnformation about the Force Structure. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence minOccurs="0"> 

<xs:element name="Name" type="xs:string" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The name of the Force Structure. </xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs:element name="FileName" type="xs:string" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The file name of the Force 
Structure. </xs:documentation> 

</xs:annotation> 

</xs:element> 
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<xs:element name="Description" type="xs:string" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A brief description of wha the Force Structure 
is.</xs:documentation> 

</xs:annotation> 

</xs:eiement> 

<xs:eiement name="Purpose" type="xs:string" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A brief description for why the Force Structure was 
created. </xs:documentation> 

</xs:annotation> 

</xs:eiement> 

<xs:element name="CreatedBy" type="xs:string" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The name of the person or group who created the Force 
Structure. </xs:documentation> 

</xs:annotation> 

</xs:eiement> 

<xs:element name="CreationDate" type="xs:date" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The date the Force Structure was 
created. </xs:documentation> 

</xs:annotation> 

</xs:eiement> 

<xs:eiement name="LastModifiedBy" type="xs:string" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>The name of the person or group who iast modified the 
Force Structure. </xs:documentation> 

</xs:annotation> 

</xs:eiement> 

<xs:eiement name="LastModifiedDate" type="xs:date" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>The date of the last modification to the Force 
Structure. </xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute name="extracted" type="xs:boolean" use="optional" default="false"> 
<xs:annotation> 

<xs:documentation>A flag to indicate whether or not the Force Structure was 
extracted. Extracted Force Structures can have only one relationship type.</xs:documentation> 
</xs:annotation> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element name="Resource"> 

<xs:annotation> 

<xs:documentation>This is a grouping element for all Resources. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Personnel" minOccurs="0" maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation>This is a container element for Personnel resource 
data.</xs:documentation> 

</xs:annotation> 
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<xs:complexType> 

<xs:sequence> 

<xs:element name="Description" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The description of a military occupational 
specialty code of a person in a military unit. This field is not used in MIDB.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="1 10"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Grade" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Pay grade of personnel assigned to a unit. 

This field is not used in MIDB.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="3"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Required" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of personnel 
required by the Unit to perform its wartime mission. For MIDB units this is relative to the parent 
entity, the total number of military personnel assessed to be war authorized 
(WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="Authorized" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of personnel 
to be assigned to the Unit to perform its peacetime mission. For MIDB units this is relative to the 
parent entity, the total number of military personnel assessed to be peacetime authorized 
(PA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="OnHand" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of personnel 
present for duty in the unit. For MIDB units this is relative to the parent entity, the total number 
of military personnel assessed to be on-hand (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute name="code" use="required"> 

<xs:annotation> 

<xs:documentation>Military Occupation Specialty (MOS) code or job 
code of personnel assigned to a military unit. This Field is not used in 
MIDB.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 
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<xs:maxLength value="7"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element name="Equipment" minOccurs="0" maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation>This is a container eiement for Equipment resource 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="Description" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Equipment nomenclature associated with the 
equipment code.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="65"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Required" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units thsi is the quantity of equipment 
required by the Unit to perform its wartime mission. For MIDB units this is relative to the parent 
entity, the total number of military equipment assessed to be war authorized 
(WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="Authorized" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of equipmenti 
to be assigned to the Unit to perform its peacetime mission. For MIDB units this is relative to the 
parent entity, the total number of military equipment assessed to be peacetime authorized 
(PA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="OnHand" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of equipment 
on hand in the unit. For MIDB units this is relative to the parent entity, the total number of 
military equipment assessed to be on-hand (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute name="code" use="required"> 

<xs:annotation> 

<xs:documentation>Unique code assigned to each piece of 
equipment. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="15"/> 
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</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element name="Aircraft" minOccurs="0" maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation>This is a container eiement for Aircraft resource 
data.</xs:documentation> 

</xs:annotation> 

<xs:compiexType> 

<xs:sequence> 

<xs:eiement name="Description" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Aircraft nomenclature associated with each 
aircraft code.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="48"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="Required" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of aircraft 
required by the Unit to perform its wartime mission. For MIDB units this is relative to the parent 
entity, the total number of military aircraft assessed to be war authorized 
(WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="Authorized" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of aircrafti to 
be assigned to the Unit to perform its mission. For MIDB units this is relative to the parent 
entity, the total number of military aircraft assessed to be peacetime authorized 
(PA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="OnHand" type="xs:short" minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For US units this is the quantity of aircraft on 
hand in the unit. For MIDB units this is relative to the parent entity, the total number of military 
aircraft assessed to be on-hand (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute name="code" use="required"> 

<xs:annotation> 

<xs:documentation>A unique code that is assigned to each 
aircraft. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:maxLength value="15"/> 

</xs:restriction> 
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</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:schema> 
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APPENDIX B. EXTRACTED UOB UNIT FILE VERSION 7.7 


This unit file was extracted from the UOB version 7.7. It serves as a 

representation compliant with the UOB version 7.7 schema used during the 

C2IEDM to UOB transformation. This is what the result file may look like when 

the transformation is completely finished. 

<?xml version="1.0" encoding="UTF-8"?> 

<UOB xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="UOB Schema 7.7.xsd"> 

<ForceStructurelnformation> 

<Name/> 

<FileName/> 

<Description/> 

<Purpose/> 

<CreatedBy/> 

<CreationDate>2004-04-15</CreationDate> 

<LastModifiedBy/> 

<LastModifiedDate>2004-04-15</LastModifiedDate> 

</ForceStructurelnformation> 

<Relationships> 

<Relationship type="Operational Control"> 

<Assigned> 

<UnitNode UIC="WG2LA07> 

</Assigned> 

</Relationship> 

</Relationships> 

<Units> 

<Unit UIC="WG2LA0" dataSource="ARMYTOE"> 

<Name>1ST SQDN 3D ARMORED CAVALRY, A CAV TRP, CAV SQDN</Name> 
<TypeCode> </TypeCode> 

<LevelCode> </LevelCode> 

<TotalPersonnel> 

<Authorized>132</Authorized> 

<OnFland>132</OnHand> 

</TotalPersonnel> 

<SRC> 

<Code>1 7487L000</Code> 

<Name>CAV TRP, CAV SQDN</Name> 

</SRC> 

<OpfacRule> 

<Code>AB200</Code> 

<Title>AR CO/CAV TRP CDR (TRACK)</Title> 

</OpfacRule> 

<SymbolCode>S*G*UCRVA-*****</SymbolCode> 

<Resource> 

<Personnel code="92Y30"> 

<Description>SUPPLY SGT</Description> 

<Grade>E6</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 
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<Personnel code="92A1 0"> 

<Description>EQUIP REC/PARTS SP</Description> 
<Grade>E4</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19D10"> 

<Description>CARRIER DRIVER</Description> 
<Grade>E4</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="92A20"> 

<Description>EQUIP REC/PARTS SGT</Description> 
<Grade>E5</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="92Y10"> 

<Description>ARMORER</Description> 

<Grade>E4</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="12C00"> 

<Description>COMMANDER</Description> 

<Grade>03</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19D10"> 

<Description>VEHICLE DRIVER</Description> 
<Grade>E3</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="63T10"> 

<Description>BFV SYS AUTO MECH</Description> 
<Grade>E3</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="63T10"> 

<Description>BFV SYS AUTO MECH</Description> 
<Grade>E4</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="12C00"> 

<Description>EXECUTIVE OFFICER</Description> 
<Grade>02</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19D20"> 

<Description>CFV GUNNER</Description> 
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<Grade>E5</Grade> 

<Required>13</Required> 

<Authorized>13</Authorized> 

</Personnel> 

<Personnel code="19D10"> 

<Description>CFV DRIVER</Description> 
<Grade>E4</Grade> 

<Required>13</Required> 

<Authorized>13</Authorized> 

</Personnel> 

<Personnel code="63T10"> 

<Description>RECOVERY VEH OPR</Description> 
<Grade>E4</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19Z5M"> 

<Description>FIRST SERGEANT</Description> 
<Grade>E8</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="63T20"> 

<Description>BFV SYS AUTO MECH</Description> 
<Grade>E5</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="54B20"> 

<Description>NBC NCO</Description> 
<Grade>E5</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19K10"> 

<Description>TANK CREWMAN</Description> 
<Grade>E4</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Personnel code="12C00"> 

<Description>PLATOON LEADER</Description> 
<Grade>02</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="45E10"> 

<Description>M1 ABRAMS TK TRT MECH</Description> 
<Grade>E3</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="45E10"> 

<Description>M1 ABRAMS TK TRT MECH</Description> 
<G rade> E4</G rade> 

<Required>1 </Required> 


115 


<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="1 9K40"> 

<Description>PLATOON SERGEANT</Description> 
<Grade>E7</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="19D10"> 

<Description>SCOUT</Description> 

<Grade>E3</Grade> 

<Required>12</Required> 

<Authorized>12</Authorized> 

</Personnel> 

<Personnel code="19D10"> 

<Description>SCOUT</Description> 

<Grade>E4</Grade> 

<Required>12</Required> 

<Authorized>12</Authorized> 

</Personnel> 

<Personnel code="1 1C10"> 

<Description>ASSISTANT GUNNER</Description> 
<Grade>E3</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="19K30"> 

<Description>TANK CDR/MASTER GUNNER</Description> 
<Grade>E6</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19K20"> 

<Description>GUNNER/ASSISTANT TC</Description> 
<Grade>E5</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Personnel code="1 1C40"> 

<Description>SECTION LEADER</Description> 
<Grade>E7</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19D30"> 

<Description>SQUAD LEADER</Description> 
<Grade>E6</Grade> 

<Required>4</Required> 

<Authorized>4</Authorized> 

</Personnel> 

<Personnel code="19D40"> 

<Description>PLATOON SERGEANT</Description> 
<Grade>E7</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 
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<Personnel code="63E10"> 

<Description>M1 TANK AUTO MECH</Description> 
<Grade>E4</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="63E40"> 

<Description>M1 TANK MAINT SUPV</Description> 
<Grade>E7</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="12B00"> 

<Description>PLATOON LEADER</Description> 
<Grade>02</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="1 1C10"> 

<Description>CARRIER DRIVER</Description> 
<Grade>E4</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="19D30"> 

<Description>SECTION LEADER</Description> 
<Grade>E6</Grade> 

<Required>4</Required> 

<Authorized>4</Authorized> 

</Personnel> 

<Personnel code="45T10"> 

<Description>BFVS TURRET MECH</Description> 
<Grade>E4</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="45T20"> 

<Description>BFVS TURRET MECH</Description> 
<Grade>E5</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="1 1C10"> 

<Description>GUNNER</Description> 

<Grade>E4</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="1 1C30"> 

<Description>SQUAD LEADER</Description> 
<Grade>E6</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="63E20"> 

<Description>RECOVERY VEH OPR</Description> 
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<Grade>E5</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Personnel code="19K10"> 

<Description>TANK CREWMAN (LOADER)</Description> 
<Grade>E3</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Personnel code="19K30"> 

<Description>TANK COMMANDER</Description> 

<Grade>E6</Grade> 

<Required>4</Required> 

<Authorized>4</Authorized> 

</Personnel> 

<Personnel code="63T30"> 

<Description>BFV SYS MECH</Description> 

<Grade>E6</Grade> 

<Required>1 </Required> 

<Authorized>1 </Authorized> 

</Personnel> 

<Equipment code="N04732"> 

<Description>NIGHT VISION SIGHT INDIVIDUAL SERVED WEAPON: 
AN/PVS-4</Description> 

<Required>12</Required> 

</Equipment> 

<Equipment code="E03826"> 

<Description>ELECTRONIC TEST SET: TS-4348/UV</Description> 
<Required>5</Required> 

</Equipment> 

<Equipment code="W02526"> 

<Description>TESTER AIR FLOW: USED ON VEHICLES W/GAS 
PARTICULATE FILTER UNITS</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="R59023"> 

<Description>REELING MACHINE CABLE HAND: RL-31</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="U05008"> 

<Description>SPLICING KIT TELEPHONE CABLE: MK-356/G</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="B07126"> 

<Description>AXLE CABLE REEL: RL-27</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="C18514"> 

<Description>COMPUTER SET: DIGITAL OL-583/TYQ</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="T40405"> 

<Description>TAPE READER GENERAL PURPOSE: KOI- 
1 8/TSEC</Description> 

<Required>2</Required> 
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</Equipment> 

<Equipment code="V3121 1 "> 

<Description>TELEPHONE SET: TA-312/PT</Description> 
<Required>9</Required> 

</Equipment> 

<Equipment code="R44999"> 

<Description>RADIO SET: AN/VRC-89F(C)</Description> 
<Required>7</Required> 

</Equipment> 

<Equipment code="R31 061 "> 

<Description>RADIAC SET: AN/UDR-13</Description> 
<Required>28</Required> 

</Equipment> 

<Equipment code="R56742"> 

<Description>REEL EQUIPMENT: CE-1 1</Description> 

<Required>18</Required> 

</Equipment> 

<Equipment code="R30925"> 

<Description>RADIAC SET: AN/PDR-75</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="M60449"> 

<Description>MULTIMETER DIGITAL: AN/PSM-45</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="C68719"> 

<Description>CABLE TELEPHONE: WD-1/TT DR-8 1/2 KM</Description> 
<Required>46</Required> 

</Equipment> 

<Equipment code="C68856"> 

<Description>CABLE TELEPHONE: WD-1/TT RL-159/U 2 KM</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="L91 975"> 

<Description>MACHINE GUN CALIBER .50: HB FLEXIBLE (GROUND AND 
VEHICLE) W/E</Description> 

<Required>16</Required> 

</Equipment> 

<Equipment code="R68146"> 

<Description>RADIO SET: AN/VRC-91 F(C)</Description> 

<Required>14</Required> 

</Equipment> 

<Equipment code="L67964"> 

<Description>LIGHTWEIGHT DIGITAL FACSIMILE: AN/UXC-7</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="M12418"> 

<Description>MASK CHEMICAL BIOLOGICAL: M40</Description> 
<Required>14</Required> 

</Equipment> 

<Equipment code="R591 60"> 

<Description>REELING MACHINE CABLE HAND: RL-39</Description> 
<Required>27</Required> 

</Equipment> 

<Equipment code="D60801"> 
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<Description>DIGITAL NON-SECURE VOICE TERMINAL W/DIGITAL DATA 
PORT: TA-1042A/</Description> 

<Requirecl>1 </Required> 

</Equipment> 

<Equipment code="N95862"> 

<Description>NAVIGATION SET SATILLITE SYSTEMS: AN/PSN- 

1 1</Description> 

<Required>30</Required> 

</Equipment> 

<Equipment code="K53748"> 

<Description>HOSE COT RUB LINE: M-F CPLG 1-1/2 IN 1-1/2 NPSH 25 FT 
LONG</Description> 

<Required>4</Required> 

</Equipment> 

<Equipment code="C89145"> 

<Description>CAMOUFLAGE SCREEN SYSTEM: WOODLAND LT WT RADAR 
SCAT W/0 SPT SYS</Description> 

<Required>92</Required> 

</Equipment> 

<Equipment code="T61494"> 

<Description>TRUCK UTILITY: CARGO/TROOP CARRIER 1-1/4 TON 4X4 W/E 
(HMMWV)</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="R20684"> 

<Description>RADIAC SET: AN/VDR-2</Description> 

<Required>1 1 </Required> 

</Equipment> 

<Equipment code="C05701"> 

<Description>MONITOR CHEMICAL AGENT:</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="C89070"> 

<Description>CAMOUFLAGE SCREEN SUPPORT SYSTEM: 
WOODLAND/DESERT</Description> 

<Required>92</Required> 

</Equipment> 

<Equipment code="R68044"> 

<Description>RADIO SET: AN/VRC-90F(C)</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="W51 91 0"> 

<Description>TOOL KIT SMALL ARMS REPAIRMAN: 
ORDNANCE</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="A33020"> 

<Description>ALARM: CHEMICAL AGENT AUTOMATIC M22</Description> 
<Required>1 1 </Required> 

</Equipment> 

<Equipment code="S64488"> 

<Description>SPEECH SCTY EQUIP DIGITAL SUBSCRIBER VOICE 
TERMINAL: TSEC/KY-68</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="W98825"> 
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<Description>TRAILER TANK: WATER 400 GALLON 1-1/2 TON 2 WHEEL 
W/E</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="K24862"> 

<Description>HEATER DUCT TYPE PTBL: GAS 250000 BTU WHL 
MTD</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="A79381 "> 

<Description>ANTENNA GROUP: OE-254()/GRC</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="E63728"> 

<Description>COMPASS MAGNETIC UNMOUNTED: MIL 
GRADUATIONS</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="W33004"> 

<Description>TOOL KIT GENERAL MECHANICS: AUTOMOTIVE</Description> 
<Required>9</Required> 

</Equipment> 

<Equipment code="L44595"> 

<Description>LAUNCHER GRENADE 40 MILLIMETER: SOLE SHOT RIFLE 
MTD DTCHBLE W/E</Description> 

<Required>16</Required> 

</Equipment> 

<Equipment code="T49947"> 

<Description>TENT: LIGHTWEIGHT MAINTENANCE ENCLOSURE 
(LME)</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="T55957"> 

<Description>TERMINAL RADIO-TELEPHONE MOBILE SUBSCRIBER: 
AN/VRC-97</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="U81707"> 

<Description>SWITCHBOARD TELEPHONE MANUAL: SB- 
22/PT</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="M74364"> 

<Description>MOUNT GUN: RING CAL .50</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="R67296"> 

<Description>RADIO SET: AN/VRC-87F(C)</Description> 
<Required>4</Required> 

</Equipment> 

<Equipment code="Z63141"> 

<Description>MAST ANTENNA 10 METERS: AB-XXX</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="C18446"> 

<Description>COMPUTER SET: DIGITAL OL-582/TYQ</Description> 
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<Required>1 </Required> 

</Equipment> 

<Equipment code="E70064"> 

<Description>COMP UNIT RCP: TRK 2 WHL PNEU TIRES GAS DRVN 5 CFM 
175 PSI</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="D1 1538"> 

<Description>CARRIER COMMAND POST: LIGHT TRACKED</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="W34648"> 

<Description>TOOL KIT CARPENTERS: ENGINEER SQUAD 
W/CHEST</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="N05482"> 

<Description>NIGHT VISION GOGGLE: AN/PVS-7B</Description> 
<Required>90</Required> 

</Equipment> 

<Equipment code="G18358"> 

<Description>GEN SET: DED SKID MTD 3KW 60HZ</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="T31872"> 

<Description>TELEPHONE WIRE WITH REEL: MX-10891/G</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="C05541"> 

<Description>CONTROL RECEIVER-TRANSMITTER: C- 
11561 (C)/U</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="D78555"> 

<Description>DATA TRANSFER DEVICE: AN/CYZ-10</Description> 
<Required>44</Required> 

</Equipment> 

<Equipment code="M18526"> 

<Description>MASK CHEMICAL BIOLOGICAL: COMBATVEHICLE 
M42</Description> 

<Required>1 1 8</Required> 

</Equipment> 

<Equipment code="R95035"> 

<Description>RIFLE 5.56 MILLIMETER: M16A2</Description> 
<Required>25</Required> 

</Equipment> 

<Equipment code="M75577"> 

<Description>MOUNT TRIPOD MACHINE GUN: HEAVY CALIBER 

50</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment code="T25726"> 

<Description>TONE-SIGNALLING ADAPTER: TA-977( )/PT</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="B67766"> 
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<Description>BINOCULAR: MODULAR CONSTRUCTION MIL SCALE 
RETICLE 7X50MM W/E</Description> 

<Required>26</Required> 

</Equipment> 

<Equipment code="P98152"> 

<Description>PISTOL 9MM AUTOMATIC: M9</Description> 
<Required>78</Required> 

</Equipment> 

<Equipment code="W32593"> 

<Description>SHOP EOUIPMENT AUTO MAINT AND REPAIR: OM COMMON 
NO 1 LESS POWER</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="D10788"> 

<Description>DIGITAL DATA SET: AN/PSG-7V1</Description> 
<Required>6</Required> 

</Equipment> 

<Equipment code="G02341"> 

<Description>DETECTING SET MINE: PTBL METALLIC (AN/PSS- 
11)</Description> 

<Required>4</Required> 

</Equipment> 

<Equipment code="N04596"> 

<Description>NIGHT VISION SIGHT CREW SERVED WEAPON: AN/TVS- 

5</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment code="R97234"> 

<Description>RIFLE 5 56 MILLIMETER: M4</Description> 
<Required>48</Required> 

</Equipment> 

<Equipment code="R45543"> 

<Description>RADIO SET: AN/VRC-92F(C)</Description> 
<Required>4</Required> 

</Equipment> 

<Equipment code="T60081"> 

<Description>TRUCK CARGO: 4X4 LMTV W/E</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="T96564"> 

<Description>TRAILER FLAT BED: M1082 TRLR CARGO LMTV 
W/DROPSIDES</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="B49272"> 

<Description>BAYONET-KNIFE: W/SCABBARD FOR M16A1 
RIFLE</Description> 

<Required>132</Required> 

</Equipment> 

<Equipment code="C18234"> 

<Description>CARRIER PERSONNEL FULL TRACKED: ARMORED 
(RISE)</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="T92889"> 
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<Description>TEST SET: ELECT SYS AN/PSM-95 FOR SOLDIERS PORT ON- 
SYS REP TOOL</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="R30895"> 

<Description>RADIO SET: AN/GRC-213</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="T06859"> 

<Description>TEST SET: COMMON CORE (STE-M1/FVS)</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="M92420"> 

<Description>MACHINE GUN 7.62 MILLIMETER: FIXED RH 
FEED</Description> 

<Required>13</Required> 

</Equipment> 

<Equipment code="L44031"> 

<Description>LAUNCHER GRENADE ARMAMENT SUBSYSTEM: 
M257</Description> 

<Required>13</Required> 

</Equipment> 

<Equipment code="K47623"> 

<Description>KY-99: MINTERM</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="L44748"> 

<Description>LAUNCHER GRENADE ARMAMENT SUBSYSTEM: SCREEN 
RP M259</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="A10769"> 

<Description>ADAPTER HARDWARE: FVS PECULIAR (STE- 
M1/FVS)</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="R50681"> 

<Description>RECOVERY VEHICLE FULL TRACKED: MEDIUM</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="F60530"> 

<Description>FIGHTING VEHICLE: FULL TRACKED CAVALRY HI 
SURVIVABILITY (CFV)</Description> 

<Required>13</Required> 

</Equipment> 

<Equipment code="V98788"> 

<Description>POWER SUPPLY VEHICLE: HYP-57/TSEC</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="T60149"> 

<Description>TRUCK CARGO: 4X4 LMTV W/E W/W</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="S35741 "> 

<Description>SAW CHAIN: GAS DRVN BAR FRAME 
W/ACCESS/COMPONENTS</Description> 
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<Required>4</Required> 

</Equipment> 

<Equipment code="W48074"> 

<Description>TOOL KIT PIONEER ENGINEER COMBAT PLATOON: TOOLS 
FOR MANUAL LABOR</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="M74849"> 

<Description>MINI EYESAFE LASER INFRARED OBSERVATION SET 
(MELIOS): AN/PVS-6</Description> 

<Required>12</Required> 

</Equipment> 

<Equipment code="L44612"> 

<Description>LAUNCHER GRENADE ARMAMENT SUBSYSTEM: 
SCREENING RED PHOSPHO M239</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="P06148"> 

<Description>PLATOON EARLY WARNING SYSTEM: AN/TRS- 
2(V)</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment code="C96840"> 

<Description>CONTROL REMOTE LANDMINE SYSTEM: M71</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="T45593"> 

<Description>SIGHT BORE OPTICAL:</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="P07900"> 

<Description>PLOTTING BOARD INDIRECT FIRE: AZIMUTH</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="Y85377"> 

<Description>WRENCH TOROUE: 3/4 IN SO MALE DRIVE 600 FT-LB 
CAPACITY</Description> 

<Required>3</Required> 

</Equipment> 

<Equipment code="L92352"> 

<Description>MACHINE GUN 7.62 MILLIMETER: FIXED</Description> 
<Required>18</Required> 

</Equipment> 

<Equipment code="P70517"> 

<Description>PURGING KIT FIRE CONTROL: ORG MAINT</Description> 
<Required>1 </Required> 

</Equipment> 

<Equipment code="V35477"> 

<Description>TELESCOPE STRAIGHT: MILITARY</Description> 
<Required>12</Required> 

</Equipment> 

<Equipment code="L44680"> 

<Description>LAUNCHER GRENADE SMOKE: SCREENING RP 
M250</Description> 

<Required>9</Required> 

</Equipment> 
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<Equipment code="Y03104"> 

<Description>VIEWER INFRARED: AN/PAS-7</Description> 

<Required>12</Required> 

</Equipment> 

<Equipment code="T58051"> 

<Description>TOOL KIT MECHANICS;</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="M68405"> 

<Description>MORTAR 120 MILLIMETERS:</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="N05050"> 

<Description>NIGHT VISION SIGHT SET: AN/UAS-1 1</Description> 
<Required>6</Required> 

</Equipment> 

<Equipment code="B90494"> 

<Description>BORESIGHTING EQUIPMENT WEAPON: MUZZLE 
ALIGNMENT</Description> 

<Required>9</Required> 

</Equipment> 

<Equipment code="T13305"> 

<Description>TANK COMBAT FULL TRACKED: 120MM GUN 
Ml A2</Description> 

<Required>9</Required> 

</Equipment> 

<Equipment code="K27594"> 

<Description>KIT GROUND HOP: Ml TANK</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="W32182"> 

<Description>TOOL KIT ARTILLERY MECHANICS: ORD</Description> 
<Required>4</Required> 

</Equipment> 

<Equipment code="A10837"> 

<Description>ADAPTER HARDWARE: Ml PECULIAR (STE- 
M1/FVS)</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="L92386"> 

<Description>MACHINE GUN 7.62 MILLIMETER: LIGHT 
FLEXIBLE</Description> 

<Required>12</Required> 

</Equipment> 

<Equipment code="M68258"> 

<Description>MORTAR: SUBCALIBER INSERT 120 MILLIMETER 
M303</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="C60294"> 

<Description>COMPUTER SET BALLISTICS: MORTAR M23</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment code="M51419"> 

<Description>MISSILE SIMULATION ROUND: (TOW)</Description> 
<Required>12</Required> 
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</Equipment> 

<Equipment code="C10990"> 

<Description>CARRIER 120 MILLIMETER MORTAR: SELF PROPELLED 
ARMORED</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="E98103"> 

<Description>ELEC TRANSFER KEYING DEVICE ETKD: KYK- 
1 3/TSEC</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="F91627"> 

<Description>DEMOLITION SET EXPLOSIVE: INITIATING NON 
ELECTRIC</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="L40063"> 

<Description>LASER INFRARED OBSERVATION SET: AN/GVS- 

5</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment code="A22496"> 

<Description>AIMING CIRCLE:</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment code="A70522"> 

<Description>ADAPTER TEST ELECTRICAL SYSTEM BREAKOUT: Ml 
TANK</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="P49587"> 

<Description>PJH SURFACE VECHILE RADIO SET: AN/VSO-2(V)1 
(PJHI)</Description> 

<Required>8</Required> 

</Equipment> 

<Equipment code="T62405"> 

<Description>TOOL SET BATTALION MAINTENANCE TEAM: ARMOR/MECH 
INF/FLD ARTY</Description> 

<Required>1 </Required> 

</Equipment> 

<Equipment code="O03468"> 

<Description>OUADRANT FIRE CONTROL: GUNNERS</Description> 
<Required>1 1 </Required> 

</Equipment> 

<Equipment code="K41392"> 

<Description>KIT GROUND HOP: IFV/CFV</Description> 

<Required>1 </Required> 

</Equipment> 

</Resource> 

</Unit> 

</Units> 

</UOB> 
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APPENDIX C. C2IEDM TO UOB XSLT 


This is the XSLT created by the author to extract unit data from a C2IEDM 
instance document and transform it into a UOB schema compliant result 
document that can be used within the FAST project as an initialization file for a 
simulation. 

<?xml version="1.0" encoding="UTF-8"?> 

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 

<xsl:output method="xml" version="1.0"/> 

<xsl:template match="/"> 

<xsl:element name="UOB"> 

<xsl:element name="ForceStructurelnformation"> 

<xsl:call-template name="FileHeader"/> 

</xsl:element> 

<xsl:element name="Units"> 

<xsl:apply-templates select="BattlespaceData/OBJECT- 
ITEM/ORGANISATION/UNIT/unit-formal-abbreviated-name7> 

</xsl:element> 

</xsl:element> 

</xsl:template> 

<xsltemplate name="FileHeader"> 

<xsl:element name="Name7> 

<xsl:element name="FileName7> 

<xsl:element name="Description">Unit document generated using XSLT on XML C2IEDM 
Ver6.1 model</xsl:element> 

<xsl:element name="Purpose7> 

<xsl:element name="CreatedBy">Transformation of C2IEDM Source File to the UOB 
Format</xsl :element> 

<xsl:element name="CreationDate">2004-04-15</xsl:element> 

<xsl:element name="LastModifiedBy7> 

<xsl:element name="LastModifiedDate">2004-08-10</xsl:element> 

</xsl:template> 

<xsltemplate match="unit-formal-abbreviated-name"> 

<xsl:element name="Unit"> 

<xsl:attribute name="UIC7> 

<xsl:attribute name="dataSource7> 

<xsl:element name="Name"> 

<xsl:value-of select=".7> 

</xsl:element> 

<xsl:variable name="ObjectltemlD" select="../../../object-item-id7> 

<xsl:variable name="ObjectTypelD" select="../OBJECT-ITEM-TYPE/object-type- 

id"/> 

<xsl:call-template name="RelativeUnitLocation"> 

<xsl:with-param name="UnitObjectltemlD" select="$ObjectltemlD7> 
<xsl:with-param name="UnitObjectltemLocationlD" select="../OBJECT-ITEM- 
LOCATION/location-id7> 

</xsl:call-template> 

<xsl:call-template name="UnitTypeCategoryCode"> 

<xsl:with-param name="OTypelD" select="$ObjectTypelD7> 

</xsl:call-template> 

<xsl:call-template name="UnitTypeSizeCode"> 
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<xsl:with-param name="ObjTyplD" select="$ObjectTypelD"/> 
</xsl:call-template> 

<xsl:element name="Resource"> 

<xsl:call-template name="PersonnelHoldings"/> 

<xsl:call-template name="EquipmentHoldings"/> 

</xsl:element> 

</xsl:element> 

</xsl:template> 

<xsltemplate name="PersonnelHoldings"> 

<xsl:for-each select="../../../HOLDING"> 

<xsl:variable name="holdingObjectTypelD" select="object-type-id"/> 
<xsl:variable name="holdingObjectltemlD" select="object-item-id"/> 
<xsl:for-each select="../../OBJECT-TYPE"> 

<xsl:variable name="objectTypelD" select="object-type-id"/> 

<xsl:if test="$objectTypelD = $holdingObjectTypelD"> 

<xsl:if test="object-type-category-code /* [local-name() = 'PE']"> 
<xsl:element name="Personnel"> 

<xsl:attribute name="code"><xsl:value-of select="object-type- 

name"/></xsl :attribute> 

<xsl:call-template name="PersonnelTemplate"/> 
<xsl:call-template name="PersonnelHoldingNumbersTemplate"/> 
</xsl:element> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> 

<xsltemplate name="PersonnelTemplate"> 

<xsl:element name="Description"/> 

<xsl:element name="Grade"> 

<xsl:choose> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OFr]">01/02</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF2']">03</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF3']">04</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF4']">05</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF5']">06</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF6']">07</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF7']">08</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF8']">09</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OF9']">10</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR1']">E1</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR2']">E2</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR3']">E3</xsl:when> 
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<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR4']">E4</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR5']">E5</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR6']">E6</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR7']">E7</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR8']">W1</xsl:when> 

<xsl:when test="PERSON-TYPE/person-type-rank-code/* [local-narneQ = 
'OR9']">W2</xsl:when> 

<xsl :otherwlse>U nknown</xsl :otherwlse> 

</xsl:choose> 

</xsl:element> 

</xsl:template> 

<xsltemplate name="EqulpmentHoldlngs"> 

<xsl:for-each select="../../../HOLDING"> 

<xsl:varlable name="holdlngObjectTypelD" select="object-type-ld"/> 

<xsl:for-each select="../../OBJECT-TYPE"> 

<xsl:varlable name="objectTypelD" select="object-type-ld"/> 

<xsl:lf test="$objectTypelD = $holdlngObjectTypelD"> 

<xsl:lf test="object-type-category-code /* [local-narneQ = 'MA']"> 
<xsl:apply-templates select="MATERIEL-TYPE"/> 

</xsl:lf> 

</xsl:lf> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> 

<xsl:template match="MATERIEL-TYPE"> 

<xsl:lf test="materlel-type-category-code /* [local-narneQ = 'EQ']"> 

<xsl:element name="Equlpment"> 

<xsl:attrlbute name="code"><xsl:value-of select="../../object-type- 
name"/></xsl :attrlbute> 

<xsl:apply-templates select="./EQUIPMENT-TYPE"/> 

<xsl:eiement name="Requlred"> 

<xsl:value-of select=”../HOLDING/holdlng-operatlonal-quantlty"/> 
</xsl:element> 

<xsl:element name="Authorlzed"> 

<xsl:value-of select=”../HOLDING/holdlng-total-quantlty"/> 

</xsl:element> 

</xsl:element> 

</xsl:for-each> 

</xsl:lf> 

</xsl:template> 

<xsltemplate name="EqulpmentType"> 

<xsl:element name="Descrlptlon"> 

<xsl:choose> 

<xsl:when test="equlpment-type-category-code /* [local-narneQ = 'AIRCFT']"> 
<xsl:value-of select="AIRCRAFT-TYPE/alrcraft-type-subcategory- 

code/*/@value"> 

</xsl:when> 

<xsl:when test="equlpment-type-category-code /* [local-narneQ = 'ELCTRN']"> 
<xsl:value-of select="ELECTRONIC-EQUIPMENT-TYPE/electronlc-equlpment- 
type-subcategory-code/*/@value"> 
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</xsl:when> 

<xsl:when test="equipment-type-category-code /* [local-name() = 'ENGEQ']"> 
<xsl:value-of select="ENGINEERING-EQUIPMENT-TYPE/engineering- 
eq u i p me n t-type-categ 0 ry-cod e/*/@ va I u e"> 

</xsl:when> 

<xsl:when test="equipment-type-category-code /* [local-name() = 'LNDWEP']"> 
<xsl:value-of select="LAND-WEAPON-TYPE/land-weapon-type-category- 

code/*/@value"> 

</xsl:when> 

<xsl:when test="equipment-type-category-code /* [local-name() = 'MISCEQ']"> 
<xsl:value-of select="MISCELLANEOUS-EQUIPMENT-TYPE/miscellaneous- 
eq u i p me n t-type-categ 0 ry-cod e/*/@va I u e"> 

</xsl:when> 

<xsl:when test="equipment-type-category-code /* [local-name() = 'NBCEQ']"> 
<xsl:value-of select="NBC-EQUIPMENT-TYPE/nbc-equipment-type-category- 

code/*/@value"> 

</xsl:when> 

<xsl:when test="equipment-type-category-code /* [local-name() = 'RAIL']"> 
<xsl:value-of select="RAILCAR-TYPE/railcar-type-category-code/7@value"> 
</xsl:when> 

<xsl:when test="equipment-type-category-code /* [local-name() = 'VEHCLE']"> 
<xsl:value-of select="VEHICLE-TYPE/vehicle-type-category-code/7@value"> 
</xsl:when> 

<xsl:when test="equipment-type-category-code /* [local-name() = 'VESSEL']"> 
<xsl:value-of select="VESSEL-TYPE/vessel-type-subcategory-code/7@value"> 
</xsl:when> 

<xsl:otherwise/> 

</xsl:choose> 

</xsl:element> 

</xsl:template> 

<xsltemplate name="PersonnelHoldingNumbersTemplate"> 

<xsl:element name="Required"> 

<xsl:value-of select="HOLDING/holding-operational-quantity7> 

</xsl:element> 

<xsl:element name="Authorized"> 

<xsl:value-of select="HOLDING/holding-total-quantity7> 

</xsl:element> 

</xsl:template> 

<xsltemplate name="UnitTypeCategoryCode"> 

<xsl:param name="OTypelD7> 

<xsl:element name="DescriptionCode"> 

<xsl:for-each select="../../../../OBJECT-TYPE"> 

<xsl:variable name="LocalObjectTypelD" select="object-type-id7> 

<xsl:if test="$OTypelD = $LocalObjectTypelD"> 

<xsl:if test="object-type-category-code/* [local-name() = 'OR']"> 

<xsl:if test="ORGANISATION-TYPE/organisation-type-category-code/* 
[local-nameO = 'GVTORG']"> 

<xsl:if test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/government-organisation-type-category-code/* [local-name() = 'MILORG']"> 

<xsl:if test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/military-organisation-type-category- 
code/* [local-nameQ = 'UNIT']"> 

<xsl:choose> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category- 
code/* [local-nameO = 'COMBAT']">AAC</xsl:when> 
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<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category- 
code/* [local-nameO = 'COMSER']">AAV</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category- 
code/* [local-narneQ = 'COMSPT']">AAS</xsl:when> 

<xsl :otherwise>U</xsl :otherwise> 

</xsl:choose> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 

<xsltemplate name="UnitTypeSizeCode"> 

<xsl:param name="ObjTyplD7> 

<xsl:element name="LevelCode"> 

<xsl:for-each select="../../../../OBJECT-TYPE"> 

<xsl:variable name="LocalObjTyplD" select="object-type-id"/> 

<xsl:if test="$ObjTyplD = $LocalObjTyplD"> 

<xsl:if test="object-type-category-code/* [local-name() = 'OR']"> 

<xsl:if test="ORGANISATION-TYPE/organisation-type-category-code/* 
[local-nameO = 'GVTORG']"> 

<xsl:if test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/government-organisation-type-category-code/* [local-name() = 'MILORG']"> 

<xsl:if test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/military-organisation-type-category- 
code/* [local-nameO = 'UNIT']"> 

<xsl:choose> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'ARMY']">A</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'AGP']">AG</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'BN']">BN</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'BDE']">BDE</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'CBTTM']">CO</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'COY']">CO</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'CORPS']">CPS</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'DIV']">DIV</xsl:when> 
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<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-nameO = 'FLEET']">FLT</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-nameO = 'FLIGFIT']">FT</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-nameO = 'PLT']">PLT</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'RGT']">RGT</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'REGION']">REG</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'SECT']">SEC</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'SQUAD']">SQD</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'SQDRNA']">SQ</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'SQDRNL']">SQ</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'TEAM']">TM</xsl:when> 

<xsl:when test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unlt-type-sIze-code/* 
[local-nameO = 'WING']">WG</xsl:when> 

<xsl :otherwlse>U</xsl :otherwlse> 

</xsl:choose> 

</xsl:lf> 

</xsl:lf> 

</xsl:lf> 

</xsl:lf> 

</xsl:lf> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 

<xsltemplate name="RelatlveUnltLocatlon"> 

<xsl:param name="UnltObjectltemlD"/> 

<xsl:param name="UnltObjectltemLocatlonlD7> 

<xsl:element name="Present"> 

<xsl:element name="Name">Current Loc</xsl:element> 

<xsl:for-each select="../../../OBJECT-ITEM-LOCATION"> 

<xsl:varlable name="ObjectltemLocatlonObjectltemlD" select="object-ltem-ld"/> 
<xsl:varlable name="ObjectltemLocatlonLocatlonlD" select="locatlon-ld7> 

<xsl:for-each select="../../LOCATION'S 

<xsl:varlable name="LocatlonlD" select="locatlon-ld"/> 

<xsl:lf test="$UnltObjectltemlD = $ObjectltemLocatlonObjectltemlD"> 

<xsl:lf test="$UnltObjectltemLocatlonlD = $LocatlonlD"> 

<xsl:element name="Latltude"> 
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latitude-coordinate"/> 


<xsl:value-of select="POINT/ABSOLUTE-POINT/absolute-point- 


</xsl:element> 

<xsl:element name="Longitude"> 

<xsl:value-of select="POINT/ABSOLUTE-POINT/absolute-point- 

longitude-coordinate"/> 

</xsl:element> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 

</xsl:stylesheet> 
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APPENDIX D. C2IEDM TO UOB RESULT DOCUMENT 


This is the result document generated when the XSLT in Appendix C was 
used on a sample C2IEDM source file (instance document). Due to the size of 
the source file it is not included here but is available upon request. 


<?xml version="1.0" encoding="UTF-8"?> 

<UOB> 

<ForceStructurelnformation> 

<Name/> 

<FileName/> 

<Description>Unit document generated using XSLT on XML C2IEDM Ver 6.1 
model</Description> 

<Purpose/> 

<CreatedBy>Transformation of C2IEDM Source File to the UOB Format</CreatedBy> 
<CreationDate>2004-04-15</CreationDate> 

<LastModifiedBy/> 

<LastModifiedDate>2004-08-10</LastModifiedDate> 

</ForceStructurelnformation> 

<Units> 

<Unit UIC="" dataSource=""> 

<Name>A 1/3 ACR</Name> 

<Present> 

<Name>Current Loc</Name> 

<Latitude>lat</Latitude> 

<Longitude>long</Longitude> 

</Present> 

<DescriptionCode>AAC</DescriptionCode> 

<LevelCode>CO</LevelCode> 

<Resource> 

<Personnel code="12C"> 

<Description/> 

<Grade>03</Grade> 

<Required>1 </Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel code="11B30"> 

<Description/> 

<Grade>E6</Grade> 

<Required>2</Required> 

<Authorized>6</Authorized> 

</Personnel> 

<Equipment code="Linebacker"> 

<Description>Air-defence</Description> 

<Required>6</Required> 

<Authorized>9</Authorized> 

</Equipment> 

<Equipment code="M8 Alarm"> 

<Description>Automated biological detector</Description> 
<Required>2</Required> 

<Authorized>2</Authorized> 
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</Equipment> 

</Resource> 

</Unit> 

<Unit UIC="" dataSource=""> 

<Name>3rd Armored Cavalry Regiment</Name> 
<Present> 

<Name>Current Loc</Name> 

<Latitude>latit2</Latitude> 

<Longitude>long2</Longitude> 

</Present> 

<DescriptionCode>AAC</DescriptionCode> 
<LevelCode>RGT </LevelCode> 

<Resource> 

<Personnel code="92Y40"> 

<Description/> 

<Grade>E7</Grade> 

<Required>3</Required> 

<Authorized>5</Authorized> 

</Personnel> 

<Personnel code="92Y10"> 

<Description/> 

<Grade>E3</Grade> 

<Required>1 </Required> 
<Authorized>3</Authorized> 

</Personnel> 

<Equipmentcode="M1098 HMMWV"> 
<Description>Ambulance</Description> 
<Required>10</Required> 

<Authorized>15</Authorized> 
</Equipment> 

<Equipment code="Avenger2"> 

<Description>Air-defence</Description> 

<Required>3</Required> 

<Authorized>2</Authorized> 

</Equipment> 

</Resource> 

</Unit> 

</Units> 

</UOB> 
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APPENDIX E. AUTHOR-GENERATED XML SCHEMA FOR UOB 


This document was created by the author using the XMLSPY IDE for XML 
authoring. The content for the schema is derived from the information in the 
UOB DAT and is not the UOB governing schema. The UOB governing schema 
is found in Appendix B. This schema was developed during the early stages of 
this research when the author was unable to extract the files necessary from the 
UOB version 7.4 Toolset. Version 7.7 corrected the extraction problems. This 
schema and the UOB DAT schema differ in the manner in which they restrict 
what data is allowed in many locations of the result document. The UOB version 
7.7 schema is not as restrictive or directive as this schema. 


<?xml version="1.0" encoding="UTF-8"?> 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 

<xs:element name="UnitData"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name="AdministrativeUnitlnformation"> 

<xs:annotation> 

<xs:documentation> 

This is the information inciuding the units size by the echeion it occupies, the 
type of unit and its name or how it is refered to in formai miiitary communications. 
</xs:documentation> 

</xs:annotation> 

<xs:compiexType> 

<xs:sequence> 

<xs:eiement name="ParentUiC" type="xs:string7> 

<xs:eiement name="ParentUTC" type="xs:string7> 

<xs:eiement name="ParentULC" type="xs:string7> 

<xs:eiement name="SRC" type="xs:string7> 

<xs:eiement name="UnitUiC" type="xs:string7> 

<xs:eiement name="UnitName" type="xs:string7> 

<xs:eiement name="UnitTypeCode" type="xs:string7> 

<xs:eiement name="UnitLeveiCode"> 

<xs:simpieType> 

<xs:restriction base="xs:string"> 

<xs:enumeration vaiue="SEC7> 

<xs:enumeration vaiue="SQD7> 

<xs:enumeration vaiue="PLT7> 

<xs:enumeration vaiue="FiFT7> 

<xs:enumeration vaiue="TRP7> 

<xs:enumeration vaiue="C07> 

<xs:enumeration vaiue="SQ7> 

<xs:enumeration vaiue="BN7> 
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<xs:enumeration value="REG"/> 

<xs:enumeration value="BDE7> 

<xs:enumeration value="DIV"/> 

<xs:enumeration value="CPS7> 

<xs:enumeration value="A7> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="UnitDescriptionCode"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:enumeration value="AAC7> 

<xs:enumeration value="AAS7> 

<xs:enumeration value="AAV7> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="PresentLongitude" type="xs:string7> 

<xs:element name="PresentLatitude" type="xs:string7> 

<xs:element name="PresentLocationName" type="xs:string7> 
<xs:element name="HomeLongitude" type="xs:string7> 

<xs:element name="HomeLatitude" type="xs:string7> 

<xs:element name="HomeLocationName" type="xs:string7> 

<xs:element name="CountryCode" type="xs:string7> 

<xs:element name="ShipCategory" type="xs:string" minOccurs="07> 
<xs:element name="ShipCategoryName" type="xs:string" 

minOccurs="07> 

<xs:element name="ShipClass" type="xs:string" minOccurs="07> 
<xs:element name="ShipHullNumber" type="xs:integer" minOccurs="07> 
<xs:element name="Source" type="xs:string7> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Personnel" minOccurs="1" maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation> 

This is the information encoded from UOB. it is broken down as it is 
dispiayed in UOB and is currentiy configured for US Army units oniy. Additionai ruies need to be 
added to encompass aii US and NATO units. </xs:documentation> 

</xs:annotation> 

<xs:compiexType> 

<xs:sequence> 

<xs:eiement name="JobDescription" type="xs:string7> 

<xs:eiement name="MiiitaryOccupationSpeciaiityCode"> 
<xs:simpieType> 

<xs:restriction base="xs:string"> 

<xs:pattern vaiue="[0-9]{2}[A-Z]{1}([0-9]{2}|[0-9]{1}[A-Z]{1})7> 
</xs:restriction> 

</xs:simpieType> 

</xs:eiement> 

<xs:eiement name="MiiitaryRank"> 

<xs:simpieType> 

<xs:restriction base="xs:string"> 

<xs:enumeration vaiue="PVT7> 

<xs:enumeration vaiue="PV27> 

<xs:enumeration vaiue="PFC7> 
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<xs:enumeration value="SPC7> 

<xs:enumeration value="SGT7> 

<xs:enumeration value="SSG7> 

<xs:enumeration value="SFC7> 

<xs:enumeration value="MSG7> 

<xs:enumeration value="1SG7> 

<xs:enumeration value="SGM7> 

<xs:enumeration value="CSM7> 

<xs:enumeration value="2LT7> 

<xs:enumeration value="1LT7> 

<xs:enumeration value="CPT7> 

<xs:enumeration value="MAJ7> 

<xs:enumeration value="LTC7> 

<xs:enumeration value="C0L7> 

<xs:enumeration value="BG7> 

<xs:enumeration value="MG7> 

<xs:enumeration value="LTG7> 

<xs:enumeration value="GEN7> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="MilitaryGrade"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:enumeration value="E17> 

<xs:enumeration value="E27> 

<xs:enumeration value="E37> 

<xs:enumeration value="E47> 

<xs:enumeration value="E57> 

<xs:enumeration value="E67> 

<xs:enumeration value="E77> 

<xs:enumeration value="E87> 

<xs:enumeration value="E97> 

<xs:enumeration value="017> 

<xs:enumeration value="027> 

<xs:enumeration value="037> 

<xs:enumeration value="047> 

<xs:enumeration value="057> 

<xs:enumeration value="067> 

<xs:enumeration value="077> 

<xs:enumeration value="087> 

<xs:enumeration value="097> 

<xs:enumeration value="O107> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="NumberRequired" type="xs:nonNegativelnteger7> 
<xs:element name="NumberAuthorized" type="xs:nonNegativelnteger7> 
<xs:element name="NumberOnHand" type="xs:nonNegativelnteger7> 
</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="UnitEquipment" minOccurs="1" maxOccurs="unbounded"> 
<xs:complexType> 

<xs:sequence> 

<xs:element name="EquipmentDescription" type="xs:string7> 
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<xs:element name="EquipmentCode"> 

<xs:simpleType> 

<xs:restriction base="xs:string"> 

<xs:pattern value="[A-Z]{1 }[0-9]{5}7> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name="NumberRequired" type="xs:nonNegativelnteger"/> 
<xs:element name="NumberAuthorized" type="xs:nonNegativelnteger"/> 
<xs:element name="EquipmentPiecesOnHand" 
type="xs:nonNegativelnteger"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:schema> 
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APPENDIX F. AUTHOR-GENERATED EXAMPLE UNIT 

DOCUMENT 


The following is a manually generated XML document describing A Troop 
1®* Squadron 3'^'^ Armored Cavalry Regiment using Altova’s XMLSPY Enterprise 
Edition 2004. All of the data in this document was taken from the UOB Client 
Version 7.4 data base. Element tags are based on the descriptions used in the 
UOB toolset. This document validates with the XML Schema in Appendix E but 
is not an extracted file from the UOB database. The file extracted and used to 
conduct the transformations described in Chapter V is located in Appendix B. 

<?xml version="1.0" encoding="UTF-8"?> 

<?xml-stylesheet type="text/xsl" href="C:\Graduate Courses\Fall 04 Quarter\MV 3250 
XML\GenericTransform.xsl"?> 

<UnitData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi;noNamespaceSchemaLocation="UnitData.xsd"> 

<AdministrativeUnitlnformation> 

<ParentUIC>WG2LAA</ParentUIC> 

<ParentUTC>2YUTT</ParentUTC> 

<ParentULC>SQ</ParentULC> 

<SRC>1 7487L000</SRC> 

<UnitUIC>WG2LA0</UnitUIC> 

<UnitName>Squadron 3rd Armored Cavalry, A CAV TRP, CAV SQDN</UnitName> 
<UnitTypeCode>2</UnitTypeCode> 

<UnitLevelCode>TRP</UnitLevelCode> 

<UnitDescriptionCode>AAC</UnitDescriptionCode> 

<PresentLongitude/> 

<PresentLatitude/> 

<PresentLocationName>lraq</PresentLocationName> 

<HomeLongitude/> 

<HomeLatitude/> 

<HomeLocationName>Colorado</HomeLocationName> 

<CountryCode>US</CountryCode> 

<Source>UOB</Source> 

</AdministrativeUnitlnformation> 

<Personnel> 

<JobDescription>Assistant Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1C1 0</MilitaryOccupationSpecialityCode> 
<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1C1 0</MilitaryOccupationSpecialityCode> 
<MilitaryRank>PFC</MilitaryRank> 
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<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Carrier Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1C1 0</MilitaryOccupationSpecialityCode> 
<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Squad Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>11C30</MilitaryOccupationSpecialityCode> 
<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Section Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>11C40</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>12BOO</MilitaryOccupationSpecialityCode> 

<MilitaryRank>2LT</MilitaryRank> 

<MilitaryGrade>01</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Commander</JobDescription> 

<MilitaryOccupationSpecialityCode>12COO</MilitaryOccupationSpecialityCode> 

<MilitaryRank>CPT</MilitaryRank> 

<MilitaryGrade>03</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Executive Officer</JobDescription> 

<MilitaryOccupationSpecialityCode>12BOO</MilitaryOccupationSpecialityCode> 
<MilitaryRank>1 LT</MilitaryRank> 

<MilitaryGrade>02</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 
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<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>12COO</MilitaryOccupationSpecialityCode> 

<MilitaryRank>2LT</MilitaryRank> 

<MilitaryGrade>01</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Carrier Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Scout</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Scout</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>CFV Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Vehicle Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 
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</Personnel> 

<Personnel> 

<JobDescription>CFV Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>19D20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Squad Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>19D30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Section Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>19D30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>19D40</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnFland>0</NumberOnFland> 

</Personnel> 

<Personnel> 

<JobDescription>Tank Crew Loader</JobDescription> 

<MilitaryOccupationSpecialityCode>19K10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<NumberOnFland>0</NumberOnFland> 

</Personnel> 

<Personnel> 

<JobDescription>Tank Crewman</JobDescription> 

<MilitaryOccupationSpecialityCode>19K10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<NumberOnFland>0</NumberOnFland> 

</Personnel> 

<Personnel> 
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<JobDescription>Gunner/Assistant TC</JobDescription> 

<MilitaryOccupationSpecialityCode>19D20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Tank Commander</JobDescription> 

<MilitaryOccupationSpecialityCode>19K30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Tank Commander/Master Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>19K30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>19K40</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>First Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>19Z5M</MilitaryOccupationSpecialityCode> 

<MilitaryRank>1SG</MilitaryRank> 

<MilitaryGrade>E8</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>M1 Tank Turret Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>45E10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>M1 Tank Turret Mechanic</JobDescription> 
<MilitaryOccupationSpecialityCode>45E10</MilitaryOccupationSpecialityCode> 
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<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV Turret Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>45T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnFland>0</NumberOnFland> 

</Personnel> 

<Personnel> 

<JobDescription>BFV Turret Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>45T20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnFland>0</NumberOnFland> 

</Personnel> 

<Personnel> 

<JobDescription>NBC NCO</JobDescription> 

<MilitaryOccupationSpecialityCode>54B20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnFland>0</NumberOnFland> 

</Personnel> 

<Personnel> 

<JobDescription>M1 Tank Auto Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63E10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnFland>0</NumberOnFland> 

</Personnel> 

<Personnel> 

<JobDescription>Recovery Vehicle Operator</JobDescription> 

<MilitaryOccupationSpecialityCode>63E20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>M1 Tank Maintenance Supervisor</JobDescription> 

<MilitaryOccupationSpecialityCode>63E40</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 
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<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Recovery Vehicle Operator</JobDescription> 

<MilitaryOccupationSpecialityCode>63T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV System Auto Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV System Auto Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV System Auto Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnFland> 

</Personnel> 

<Personnel> 

<JobDescription>BFV System Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Equipment Rec/Parts Specialist (PEL Clerk)</JobDescription> 
<MilitaryOccupationSpecialityCode>92A10</MilitaryOccupationSpecialityCode> 
<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 
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<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Equip Rec/Parts Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>92A20</MilitaryOccupationSpecialityCode 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Armorer</JobDescription> 

<MilitaryOccupationSpecialityCode>92Y10</MilitaryOccupationSpecialityCode 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Supply Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>92Y30</MilitaryOccupationSpecialityCode 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<UnitEquipment> 

<EquipmentDescription>ADAPTER HARDWARE: FVS PECULIAR (STE- 
M1/FVS)</EquipmentDescription> 

<EquipmentCode>A10769</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ADAPTER HARDWARE: M1 PECULIAR (STE- 
M1/FVS)</EquipmentDescription> 

<EquipmentCode>A10837</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>AIMING CIRCLE</EquipmentDescription> 

<EquipmentCode>A22496</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ALARM, CHEMICAL AGENT AUTOMATIC 
M22</EquipmentDescription> 

<EquipmentCode>A33020</EquipmentCode> 
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<NumberRequired>1 1 </NumberRequired> 

<NumberAuthorized>1 1 </NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ANALYZER SET ENGINE: PORTABLE SOLID STATE 
(STE/ICEPM)</EquipmentDescription> 

<EquipmentCode>A56243</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ADAPTER TEST ELECTRICAL SYSTEM BREAKOUT: M1 
TANK</EquipmentDescription> 

<EquipmentCode>A70522</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ANTENNA GROUP: OE-254()/GRC</EquipmentDescription> 

<EquipmentCode>A79381</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>AXLE CABLE REEL: RL-27</EquipmentDescription> 

<EquipmentCode>B07126</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>1</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>BAYONET-KNIFE: W/SCABBARD FOR M16A1 
RIFLE</EquipmentDescription> 

<EquipmentCode>B49272</EquipmentCode> 

<NumberRequired>132</NumberRequired> 

<NumberAuthorized>132</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>BINOCULAR: MODULAR CONSTRUCTION MIL SCALE 
RETICLE 7X50MM W/E</EquipmentDescription> 
<EquipmentCode>B67766</EquipmentCode> 
<NumberRequired>26</NumberRequired> 
<NumberAuthorized>26</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>BORESIGHTING EQUIPMENT WEAPON: MUZZLE 
ALIGNMENT</EquipmentDescription> 

<EquipmentCode>B90494</EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 
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<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CONTROL RECEIVER-TRANSMITTER: C- 
11561 (C)/LJ</EquipmentDescription> 

<EquipmentCode>C05541</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MONITOR CHEMICAL AGENT</EquipmentDescription> 

<EquipmentCode>C05701</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CARRIER 120 MILLIMETER MORTAR: SELF PROPELLED 
ARMORED</EquipmentDescription> 

<EquipmentCode>C10990</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CARRIER PERSONNEL FULL TRACKED: ARMORED 
(RISE)</EquipmentDescription> 

<EquipmentCode>C18234</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMPUTER SET: DIGITAL OL- 
582/TYQ</EquipmentDescription> 

<EquipmentCode>C18446</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMPUTER SET: DIGITAL OL- 
582/TYQ</EquipmentDescription> 

<EquipmentCode>C18514</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CABLE TELEPHONE: WD-1/TT DR-8 1/2 
KM</EquipmentDescription> 

<EquipmentCode>C68719</EquipmentCode> 

<NumberRequired>46</NumberRequired> 

<NumberAuthorized>46</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CABLE TELEPHONE: WD-1/TT RL-159/U 2 
KM</EquipmentDescription> 

<EquipmentCode>C68856</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CAMOUFLAGE SCREEN SUPPORT SYSTEM: 
WOODLAND/DESERT</EquipmentDescription> 

<EquipmentCode>C89070</EquipmentCode> 

<NumberRequired>92</NumberRequired> 

<NumberAuthorized>92</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CAMOUFLAGE SCREEN SYSTEM: WOODLAND LT WT 
RADAR SCAT W/0 SPT SYS</EquipmentDescription> 
<EquipmentCode>C89145</EquipmentCode> 
<NumberRequired>92</NumberRequired> 
<NumberAuthorized>92</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CONTROL REMOTE LANDMINE SYSTEM: 

M71 </EquipmentDescription> 

<EquipmentCode>C96840</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DIGITAL DATA SET: AN/PSG-7V1</EquipmentDescription> 
<EquipmentCode>D10788</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CARRIER COMMAND POST: LIGHT 
TRACKED</EquipmentDescription> 

<EquipmentCode>D1 1 538</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DIGITAL NON-SECURE VOICE TERMINAL W/DIGITAL DATA 
PORT: TA-1 042A</EquipmentDescription> 

<EquipmentCode>D60801</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 


153 


<UnitEquipment> 

<EquipmentDescription>DATA TRANSFER DEVICE: AN/CYZ-10</EquipmentDescription> 
<EquipmentCode>D78555</EquipmentCode> 

<NumberRequired>44</NumberRequired> 

<NumberAuthorized>44</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CHARGER BATTERY: PP-34/MSM</EquipmentDescription> 
<EquipmentCode>D99573</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ELECTRONIC TEST SET: TS-4348/UV</EquipmentDescription> 
<EquipmentCode>E03826</EquipmentCode> 

<NumberRequired>5</NumberRequired> 

<NumberAuthorized>5</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMPASS MAGNETIC UNMOUNTED: MIL 
GRADUATIONS</EquipmentDescription> 

<EquipmentCode>E63728</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMP UNIT RCP: TRK 2 WHL PNEU TIRES GAS DRVN 5 CFM 
175 PSI</EquipmentDescription> 

<EquipmentCode>E70064</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ELEC TRANSFER KEYING DEVICE ETKD: KYK- 
13/TSEC</EquipmentDescription> 

<EquipmentCode>E98103</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>FIGHTING VEHICLE: FULL TRACKED CAVALRY HI 
SURVIVABILITY (CFV)</EquipmentDescription> 

<EquipmentCode>F60530</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DEMOLITION SET EXPLOSIVE: INITIATING NON 
ELECTRIC</EquipmentDescription> 
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<EquipmentCode>F91627</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DETECTING SET MINE: PTBL METALLIC (AN/PSS- 
11 )</EquipmentDescription> 

<EquipmentCode>G02341</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>GEN SET: DED SKID MTD 3KW 60HZ</EquipmentDescription> 
<EquipmentCode>G18358</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>HEATER DUCT TYPE PTBL: GAS 250000BTU WHL 
MTD</EquipmentDescription> 

<EquipmentCode>K24862</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>KIT GROUND HOP: M1 TANK</EquipmentDescription> 
<EquipmentCode>K27594</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>KIT GROUND HOP: IFV/CFV</EquipmentDescription> 
<EquipmentCode>K41392</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>KY-99: MINTERM</EquipmentDescription> 
<EquipmentCode>K47623</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>HOSE COT RUB LINE: M-F CPLG 1-1/2 IN 1-1/2 NPSH 25 FT 
LONG</EquipmentDescription> 

<EquipmentCode>K53748</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LASER INFRARED OBSERVATION SET: AN/GVS- 
5</EquipmentDescription> 

<EquipmentCode>L40063</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER GRENADE ARMAMENT SUBSYSTEM: 
M257</EquipmentDescription> 

<EquipmentCode>L44031</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER GRENADE 40 MILLIMETER: SGLE SHOT RIFLE 
MTD DTCHBLE W/E</EquipmentDescription> 

<EquipmentCode>L44595</EquipmentCode> 

<NumberRequired>16</NumberRequired> 

<NumberAuthorized>16</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER GRENADE ARMAMENT SUBSYSTEM: 
SCREENING RED PHOSPHO M239</EquipmentDescription> 
<EquipmentCode>L44612</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER GRENADE SMOKE: SCREENING RP 
M250</EquipmentDescription> 

<EquipmentCode>L44680</EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER GRENADE ARMAMENT SUBSYSTEM: SCREEN 
RP M259</EquipmentDescription> 

<EquipmentCode>L44748</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LIGHTWEIGHT DIGITAL FACSIMILE: AN/UXC- 
7</EquipmentDescription> 

<EquipmentCode>L67964</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE GUN CALIBER .50: HB FLEXIBLE (GROUND AND 
VEHICLE) W/E</EquipmentDescription> 

<EquipmentCode>L91975</EquipmentCode> 

<NumberRequired>16</NumberRequired> 

<NumberAuthorized>16</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE GUN 7.62 MILLIMETER: 
FIXED</EquipmentDescription> 

<EquipmentCode>L92352</EquipmentCode> 

<NumberRequired>18</NumberRequired> 

<NumberAuthorized>18</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MASK CHEMICAL BIOLOGICAL: M40</EquipmentDescription> 
<EquipmentCode>M12418</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MASK CHEMICAL BIOLOGICAL: COMBAT VEHICLE 
M42</EquipmentDescription> 

<EquipmentCode>M18526</EquipmentCode> 

<NumberRequired>1 1 9</NumberRequired> 

<NumberAuthorized>1 1 9</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MISSILE SIMULATION ROUND: (TOW)</EquipmentDescription> 
<EquipmentCode>M51419</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MULTIMETER DIGITAL: AN/PSM-45</EquipmentDescription> 
<EquipmentCode>M60449</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MORTAR: SUBCALIBER INSERT 120 MILLIMETER 
M303</EquipmentDescription> 

<EquipmentCode>M68258</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MORTAR 120 MILLIMETERS</EquipmentDescription> 
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<EquipmentCode>M68405</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MOUNT GUN: RING CAL .50</EquipmentDescription> 

<EquipmentCode>M74364</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MINI EYESAFE LASER INFRARED OBSERVATION SET 
(MELIOS): AN/PVS-6</EquipmentDescription> 

<EquipmentCode>M74849</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MOUNT TRIPOD MACHINE GUN: HEAVY CALIBER 
50</EquipmentDescription> 

<EquipmentCode>M75577</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE GUN 7.62 MILLIMETER: FIXED RH 
FEED</EquipmentDescription> 

<EquipmentCode>M92420</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE GUN: 7.62MM M240B</EquipmentDescription> 

<EquipmentCode>M92841</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT VISION SIGHT CREW SERVED WEAPON: AN/TVS- 
5</EquipmentDescription> 

<EquipmentCode>N04596</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT VISION SIGHT INDIVIDUAL SERVED WEAPON: 
AN/PVS-4</EquipmentDescription> 

<EquipmentCode>N04732</EquipmentCode> 

<NumberRequired>12</NumberRequired> 
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<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT VISION SIGHT SET: AN/UAS- 
11 </EquipmentDescription> 

<EquipmentCode>N05050</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT VISION GOGGLE: AN/PVS-7B</EquipmentDescription> 

<EquipmentCode>N05482</EquipmentCode> 

<NumberRequired>90</NumberRequired> 

<NumberAuthorized>90</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NAVIGATION SET SATELLITE SYSTEMS: AN/PSN- 
11 </EquipmentDescription> 

<EquipmentCode>N95862</EquipmentCode> 

<NumberRequired>30</NumberRequired> 

<NumberAuthorized>30</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PLATOON EARLY WARNING SYSTEM: AN/TRS- 
2(V)</EquipmentDescription> 

<EquipmentCode>P06148</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PLOTTING BOARD INDIRECT FIRE: 
AZIMUTH</EquipmentDescription> 

<EquipmentCode>P07900</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PJH SURFACE VEHICLE RADIO SET: AN/VSQ-2(V)1 
(PJHI)</EquipmentDescription> 

<EquipmentCode>P49587</EquipmentCode> 

<NumberRequired>8</NumberRequired> 

<NumberAuthorized>8</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PURGING KIT FIRE CONTROL: ORG 
MAINT</EquipmentDescription> 

<EquipmentCode>P70517</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 
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<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PISTOL 9MM AUTOMATIC: M9</EquipmentDescription> 

<EquipmentCode>P98152</EquipmentCode> 

<NumberRequired>78</NumberRequired> 

<NumberAuthorized>78</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>QUADRANT FIRE CONTROL: 

GUNNERS</EquipmentDescription> 

<EquipmentCode>O03468</EquipmentCode> 

<NumberRequired>1 1 </NumberRequired> 

<NumberAuthorized>1 1 </NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIAC SET: AN/VDR-2</EquipmentDescription> 
<EquipmentCode>R20684</EquipmentCode> 

<NumberRequired>1 1 </NumberRequired> 

<NumberAuthorized>1 1 </NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO SET: AN/GRC-213</EquipmentDescription> 

<EquipmentCode>R30895</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIAC SET: AN/PDR-75</EquipmentDescription> 

<EquipmentCode>R30925</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIAC SET: AN/UDR-13</EquipmentDescription> 
<EquipmentCode>R31 061 </EquipmentCode> 
<NumberRequired>28</NumberRequired> 
<NumberAuthorized>28</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO SET: AN/VRC-89D</EquipmentDescription> 

<EquipmentCode>R44931</EquipmentCode> 

<NumberRequired>7</NumberRequired> 

<NumberAuthorized>7</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO SET: AN/VRC-92D</EquipmentDescription> 

<EquipmentCode>R45475</EquipmentCode> 

<NumberRequired>4</NumberRequired> 
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<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RECOVERY VEHICLE FULL TRACKED: 
MEDIUM</EquipmentDescription> 

<EquipmentCode>R50681</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>REEL EQUIPMENT: CE-1 1</EquipmentDescription> 

<EquipmentCode>R56742</EquipmentCode> 

<NumberRequired>18</NumberRequired> 

<NumberAuthorized>18</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>REELING MACHINE CABLE HAND: RL- 
31 </EquipmentDescription> 

<EquipmentCode>R59023</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>REELING MACHINE CABLE HAND: RL- 
39</EquipmentDescription> 

<EquipmentCode>R59160</EquipmentCode> 

<NumberRequired>27</NumberRequired> 

<NumberAuthorized>27</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO SET: AN/VRC-87D</EquipmentDescription> 

<EquipmentCode>R67228</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO SET: AN/VRC-90D</EquipmentDescription> 

<EquipmentCode>R67976</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO SET: AN/VRC-91 D</EquipmentDescription> 

<EquipmentCode>R68078</EquipmentCode> 

<NumberRequired>14</NumberRequired> 

<NumberAuthorized>14</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 
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<EquipmentDescription>RIFLE 5.56 MILLIMETER: M16A2</EquipmentDescription> 

<EquipmentCode>R95035</EquipmentCode> 

<NumberRequired>50</NumberRequired> 

<NumberAuthorized>50</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RIFLE 5 56 MILLIMETER: M4</EquipmentDescription> 

<EquipmentCode>R97234</EquipmentCode> 

<NumberRequired>24</NumberRequired> 

<NumberAuthorized>24</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SAW CHAIN: GAS DRVN BAR FRAME 
W/ACCESS/COMPONENTS</EquipmentDescription> 
<EquipmentCode>S35741</EquipmentCode> 
<NumberRequired>4</NumberRequired> 
<NumberAuthorized>4</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SPEECH SCTY EQUIP DIGITAL SUBSCRIBER VOICE 
TERMINAL: TSEC/KY-68</EquipmentDescription> 
<EquipmentCode>S64488</EquipmentCode> 
<NumberRequired>1</NumberRequired> 
<NumberAuthorized>1</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TEST SET: COMMON CORE (STE- 
M1/FVS)</EquipmentDescription> 

<EquipmentCode>T06859</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TANK COMBAT FULL TRACKED: 120MM GUN 
M1 A2</EquipmentDescription> 

<EquipmentCode>T 1 3305</EquipmentCode> 
<NumberRequired>9</NumberRequired> 
<NumberAuthorized>9</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TONE-SIGNALLING ADAPTER: TA-977( 
)/PT</EquipmentDescription> 

<EquipmentCode>T25726</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TELEPHONE WIRE WITH REEL: MX- 
10891/G</EquipmentDescription> 


162 


<EquipmentCode>T31872</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SIGHT BORE OPTICAL;</EquipmentDescription> 
<EquipmentCode>T45593</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TENT: LIGHTWEIGHT MAINTENANCE ENCLOSURE 
(LME)</EquipmentDescription> 

<EquipmentCode>T49947</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TERMINAL RADIO-TELEPHONE MOBILE SUBSCRIBER: 
AN/VRC-97</EquipmentDescription> 

<EquipmentCode>T55957</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL KIT MECHANICS</EquipmentDescription> 
<EquipmentCode>T58051</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRUCK CARGO: 4X4 LMTV W/E</EquipmentDescription> 
<EquipmentCode>T60081</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRUCK CARGO: 4X4 LMTV W/E WAA/</EquipmentDescription> 
<EquipmentCode>T60149</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRUCK UTILITY: CARGO/TROOP CARRIER 1-1/4 TON 4X4 
W/E (HMMWV)</EquipmentDescription> 

<EquipmentCode>T61494</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL SET BATTALION MAINTENANCE TEAM: ARMOR/MECH 
INF/FLD ARTY</EquipmentDescription> 

<EquipmentCode>T62405</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SPLICING KIT TELEPHONE CABLE: MK- 
356/G</EquipmentDescription> 

<EquipmentCode>U05008</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SWITCHBOARD TELEPHONE MANUAL: SB- 
22/PT</EquipmentDescription> 

<EquipmentCode>U81707</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TELEPHONE SET: TA-312/PT</EquipmentDescription> 
<EquipmentCode> V31211 </EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TELESCOPE STRAIGHT: MILITARY</EquipmentDescription> 
<EquipmentCode>V35477</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>POWER SUPPLY VEHICLE: HYP- 
57/TSEC</EquipmentDescription> 

<EquipmentCode>V98788</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TESTER AIR FLOW: USED ON VEHICLES W/GAS 
PARTICULATE FILTER UNITS </EquipmentDescription> 
<EquipmentCode>W02526</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 
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<EquipmentDescription>TOOL KIT ARTILLERY MECHANICS: 
ORD</EquipmentDescription> 

<EquipmentCode>W32182</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SHOP EQUIPMENT AUTO MAINT AND REPAIR: OM COMMON 
NO 1 LESS POWER</EquipmentDescription> 

<EquipmentCode>W32593</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL KIT GENERAL MECHANICS: 
AUTOMOTIVE</EquipmentDescription> 

<EquipmentCode>W33004</EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL KIT CARPENTERS: ENGINEER SQUAD W/CHEST 
</EquipmentDescription> 

<EquipmentCode>W34648</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL KIT PIONEER ENGINEER COMBAT PLATOON: TOOLS 
FOR MANUAL LABOR</EquipmentDescription> 

<EquipmentCode>W48074</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL KIT SMALL ARMS REPAIRMAN: 
ORDNANCE</EquipmentDescription> 

<EquipmentCode>W51 91 0</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRAILER TANK: WATER 400 GALLON 1-1/2 TON 2 WHEEL 
W/E</EquipmentDescription> 

<EquipmentCode>W98825</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 
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<EquipmentDescription>VIEWER INFRARED: AN/PAS-7</EquipmentDescription> 
<EquipmentCode>Y03104</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>WRENCH TORQUE: 3/4 IN SO MALE DRIVE 600 FT-LB 
CAPACITY</EquipmentDescription> 

<EquipmentCode>Y85377</EquipmentCode> 

<NumberRequired>3</NumberRequired> 

<NumberAuthorized>3</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRAILER CARGO: LMTV 
W/DROPSIDES</EquipmentDescription> 

<EquipmentCode>Z36068</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MORTAR BALLISTIC COMPUTER: 
XM30</EquipmentDescription> 

<EquipmentCode>Z44784</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MAST ANTENNA 10 METERS: AB-XXX</EquipmentDescription> 
<EquipmentCode>Z63141</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

</UnitData> 
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